On 28.04.2017 12:06, Jonathan Perkin wrote: > * On 2017-04-24 at 13:50 BST, Joerg Sonnenberger wrote: > >> On Mon, Apr 24, 2017 at 02:07:17PM +0200, Edgar Fuß wrote: >>> Is C++n a superset of C++m for n>m? >> >> Mostly. There are a couple of things that explicitly create problems for >> m == 2003 and there is the problem of at least one semantic change that >> can potentially result in miscompiled code (destructors are tagged as >> not throwing by default in 2011). For m>=2011 it should be transparent. > > In that case what about something like this: > > https://github.com/joyent/pkgsrc/commit/e33dc10357d54315a5152ccd9895dde5e1d0f256 > > tl;dr: introduce CXX_REQD as a similar mechanism to GCC_REQD, packages > append to it what they need, then we distil it to the most recent > version and use that for the build. > > todo: set GCC_REQD based on it, i.e. if CXX_REQD>= c++11 then > automatically set GCC_REQD+=4.7 or whatever > > This is running through a bulk build at present. > >> There is also the ABI breaking mess in libstdc++ to consider of course, >> i.e. depending on how libstdc++ from GCC 5.1+ is installed, code >> compiled with -std=c++11 may or may not link correctly with -std=c++03. > > I'm coming to the conclusion that we basically punt on this, and if > users want to ensure that things work well they need to choose > up-front a suitable compiler to use for all their builds that will > satisfy all of their *_REQD. This is basically what we (Joyent) do > currently, though at some point we'll need to go to newer than GCC 4.9 > for the latest C++ stuff. > I would promote gnu++* variations always over c++* unconditionally. A user specifies c++11, c++14, c++17 and Makefiles translate it to gnu++11, gnu++14, gnu++17 etc. GNU variation is often required for portable software to Windows. I'm not convinced about using names like c++0x, they are deprecated in newer compilers. Older ones don't necessarily support all the needed features from the standard.
Attachment:
signature.asc
Description: OpenPGP digital signature