Re: Mandates explicit -std=c++XY for c++ projects
On Tue, Oct 10, 2017 at 11:38 AM, Matthias Klose <doko@debian.org> wrote:
> On 10.10.2017 08:45, Mathieu Malaterre wrote:
>> Dear all,
>>
>> Since the GCC 6 release [1], the default mode for C++ is now
>> -std=gnu++14 instead of -std=gnu++98. What this means is that upon
>> (re)compilation a library written for c++98 will be recompiled using a
>> different c++ standard (c++14 in this case), unless of course the
>> upstream package explicitly set the -std= flags with the appropriate
>> c++ version.
>>
>> The ISO committee generally describe the change in between different
>> standards [2] and in some case, one can find examples of subtle change
>> in behaviors [3] and [4].
>>
>> With this mind I'd like to make mandatory the -std=c++XY flags when
>> compiling either a c++ library or a stand-alone c++ program:
>>
>> 1. Either upstream define the explicit -std=c++XY flags by mean of its
>> build system,
>> 2. Or the package maintainers needs to explicit change the CXXFLAGS to
>> pass the appropriate version of the c++ standard. In which case this
>> should be documented in the README.Debian file.
>> 3. As a fallback, dh should initialize the CXXFLAGS with -std=gnu++98
>>
>> If there is a consensus on the following change, I'll go ahead and
>> also file a bug for lintian to scan the compilation logs in search for
>> missing -std=c++ expression when g++ command line are issued.
>
> I don't think this is a good idea, and I'm still trying to understand what
> problem you are trying to solve. It took a while until GCC had stable c++11
> support, and now you want to fallback to a 20 year old standard by default?
As said above, this is simply a fallback, I am fine with any value as
long as I can see it in the log clearly.
My point was about making the flag *explicit*, whatever value is
chosen, so that upon recompilation we gets the same symbols, the same
behavior, no FTBFS (because of deprecated feature).
> It would be better to spend some time to prepare for -std=gnu++17 instead ;)
So you have no major objection against my proposal, I feared you may
have an issue with mixed combination of stdc++ runtime lib (not sure
exactly how this is handled at low level).
Reply to: