> What do you mean with ... All I meant is that while it's not in debian / ubuntu stable, it seems to be available in the "usual" places for extras.
> GCC still claims their C++11 support is experimental [1] :-( Hmm so actually I think that's not true, I looked at your link, but it doesn't list gcc-4.9 at all, only up to gcc 4.8 Based on this stackoverflow answer I concluded that you can find the status from `info gcc`: http://stackoverflow.com/questions/21221411/when-will-gnu-c-support-c11-without-explicitly-asking-for-it This is what I get from `info gcc-4.8` c++11 c++0x The 2011 ISO C++ standard plus amendments. Support for C++11 is still experimental, and may change in incompatible ways in future releases. The name c++0x is deprecated. gnu++11 gnu++0x GNU dialect of -std=c++11. Support for C++11 is still experimental, and may change in incompatible ways in future releases. The name gnu++0x is deprecated. This is what I get from `info gcc-4.9` c++11 c++0x The 2011 ISO C++ standard plus amendments. The name c++0x is deprecated. gnu++11 gnu++0x GNU dialect of -std=c++11. The name gnu++0x is deprecated. So it looks like they now claim to fully support C++11. > I think supporting the subset that MSVC supports is a bad idea. Either we fully support C++11 or not. Yeah I would agree that that's a good idea, I only bring it up because it looks like historically we have very frequently added workarounds to support MSVC compilation. Since it looks like MSVC is pretty far behind and is now targetting C++14 instead of C++11, http://www.infoq.com/news/2013/07/vs2013_CPP_compliance/ I would guess that either we should say "only MSVC supported stuff please" or drop support. > To disable the std::auto_ptr warning you can use -Wno-deprecated-declarations with GCC (and probably also in Clang). Should we just replace the auto_ptr uses, or you think it's not a good idea? > For libpng you should mark it as system header, these warnings are normally ignored. I don't know how to mark them in SCons, but in CMake I added SYSTEM to the include_directories statement. Okay, good to know. > Additionally it would be nice to know whether C++11 compiled executable work properly; something I never tested. Yeah, agreed. > I still remain at my opinion, where I think it's too early to move to C++11, but still hope to revise that opinion in the (near) future. That seems pretty reasonable, there is no rush. > I also disagree to use lambda functions everywhere; use them where applicable. Okay, fair enough :) Best Regards, Chris Beck On Mon, Nov 10, 2014 at 3:58 PM, Mark de Wever <ko...@xs4all.nl> wrote: > On Wed, Nov 05, 2014 at 10:28:23PM -0500, chris beck wrote: > > I just wanted to write to ask what if any update / new thoughts anyone > has > > about C++11. > > > > Previously there was some discussion here: > > > > https://mail.gna.org/public/wesnoth-dev/2014-02/msg00069.html > > https://mail.gna.org/public/wesnoth-dev/2014-02/msg00071.html > > > > https://mail.gna.org/public/wesnoth-dev/2014-05/msg00002.html > > https://mail.gna.org/public/wesnoth-dev/2014-05/msg00004.html > > > > Regarding the first set: > > - Did anything ever come of the C++11 addon-server plans? Was there any > > sticking point? > > No the GSoC project failed, but that had nothing to do with the language > used. > > > Regarding the second set: > > - Does anyone have any new opinions / evaluations of the C++11 compiler > > support available now? gcc 4.9 seems quite good, I have been using it > for a > > while. It seems it's not often available in "stable distributions" of > > linuxes but it's still not too hard to get your hands on, and it appears > to > > implement almost everything. > > What do you mean with »it's still not too hard to get your hands on« ? > IMO not having it in stable distributions will prevent people from > compiling Wesnoth, it will also make it harder for packagers to build > packages. > > > my clang copy has some minor bug that prevents me from compiling some > > things, but I didn't try to fix it yet, probably it's easy. I > > understand msvc is still lagging behind -- is that something we > > consider a sticking point? How would people feel about moving only to > > "msvc C++11". > > GCC still claims their C++11 support is experimental [1] :-( > > Clang 3.5 seems to do fine, but they use the standard library shipped > with GCC. Using their own library gave me linker errors, since their > implementation of std::string differs from GCC. This caused linker > errors against a boost library (can't recall which one, but I think > program options). > > I think supporting the subset that MSVC supports is a bad idea. Either > we fully support C++11 or not. Supporting only a subset will cause > grieve. People using other compilers will too easily use features not > supported by MSVC and then have to rewrite their code to suit MSVC. > Which might be changing the design of something. Does anybody know the > exact status of MSVC? > > > - Regarding "The keyword is »idiomatic C++11«." It seems it would be > > potentially daunting to attempt to rewrite all of the 100k's of lines of > > the project in idiomatic C++11 all at once, but perhaps we could break > this > > into stages and do it over an extended period. Alternatively, everyone > > could just start using lambda functions everywhere and rewrite old code > > only as an after thought. > > I fear that »idiomatic C++11« also affect the design of some class > hierarchies, due to move support. I also disagree to use lambda > functions everywhere; use them where applicable. > > > - Regarding "I think the important thing is, that once we have done > > this, other developers can look whether they like C++11 or think it looks > > too different from C++98/03." So actually, I guess most devs right now > know > > vaguely about C++11 and may have formed some kind of opinion. Maybe it > > would be helpful to get something like a show of hands so we can see who > is > > comfortable with C++11 already / willing to learn? (I count myself in the > > latter > > category). > > I have some experience and certainly want to learn more of C++11/C++14. > > > Finally: > > - The other day, we added an extra travis build which checks C++11 > > compilation for the whole project. Currently it is set not to be strict, > > because we cannot compile without warnings. However we only get two types > > of warnings, one from something in the header of lib png (I think this > can > > and should be easily suppressed), and the other is warnings about > auto_ptr > > being deprecated. Assuming we resolve that I believe everything would be > > compiling without warnings. Would anyone thing it's worth it to do this > and > > then set the travis build to require strict compilation to pass in C++11 > > mode? Then at least we won't make negative progress on C++11 while we > > decide what to do. > > I used to compile Wesnoth in C++11 strict mode locally and that used to > work, but I haven't had time to work on Wesnoth lately so there might be > additional errors. So I think it's worth it to test with Travis. > > To disable the std::auto_ptr warning you can use > -Wno-deprecated-declarations with GCC (and probably also in Clang). > > For libpng you should mark it as system header, these warnings are > normally ignored. I don't know how to mark them in SCons, but in CMake I > added SYSTEM to the include_directories statement. > > Additionally it would be nice to know whether C++11 compiled executable > work properly; something I never tested. > > I still remain at my opinion, where I think it's too early to move to > C++11, but still hope to revise that opinion in the (near) future. > > > [1] https://gcc.gnu.org/projects/cxx0x.html > > -- > Regards, > Mark de Wever aka Mordante/SkeletonCrew > > _______________________________________________ > Wesnoth-dev mailing list > Wesnoth-dev@gna.org > https://mail.gna.org/listinfo/wesnoth-dev >
_______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
