Am 25.10.2015 um 20:31 schrieb Georg Baum:
Vincent van Ravesteijn wrote:
I thought we always wanted to support as many compilers as reasonably
possible in order to allow newcomers to easily compile LyX and to let
them contribute. Does it make sense to still support Qt 4.5, but to
require the last version of the Microsoft compiler ?
BTW I do not think that Qt 4.5 needs to be supported. One could also discuss
in principle whether support for MSVC2010 is needed, or whether we could
require 2012.
The most important reason to support C++98 in 2.2.0 is IMHO that a change so
fundamental as to switch from one standard version to another is always a
risky thing, and doing it immediately before a release is the worst timing
one could have. These changes need to be done in the development branch
directly after a stable release in order to get more experience. This is not
pure theory, simply by compiling in C++11 mode we did already find a bug in
a mature, well reputed compiler:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67557 Who tells us that there
is not another one hidden (maybe in another compiler)?
Very interesting bug, even if the code looks a bit strange.
In another project I saw speed improvements just
by enabling C++11 (I assume mainly because of the
move semantic).
Since we need to support C++98 anyway it is also clear that MSVC 2010 should
not be dropped. This eases the work of the windows people a lot: No new
dependencies are required right now, and nobody needs to learn a new version
(remember that MSVC is not only a compiler, but an IDE).
I would even support MSVC only for developers and do the
release with MinGW, would simplify compiling all the
dependencies a lot.
Finally, supporting C++98 for 2.2.0 does not cost us anything right now,
since no biger changes will happen before the release anyway, and the
existing code supports C++98. Also, those who want to compile in C++11-mode
can do so as well if they are willing to accept a higher risk. If the case
happens that backporting a bugfix to 2.2.x will be difficult (as mentioned
by Guillaume), then we can still see how to solve that problem at the time
when it happens. IMHO, a backporting difficulty caused by the need to
support the old standard is in no way different from a backporting
difficulty caused by some code refactoring. In both cases, one needs to
assess the importance of the bug fix, the cost of it and its risk. Then one
can decide whether to do it or not.
Georg
