[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Mandates explicit -std=c++XY for c++ projects

Hello Mathieu, 

Am Dienstag, den 10.10.2017, 11:45 +0200 schrieb Mathieu Malaterre:
I don't think there is much to gain from it. Whenever there is a
> > in the major version of gcc/g++ many bugs show up and all involved
> > really do a great job fixing these. IMHO switching from an older
> > C++ standard to a newer one is no different. In fact, I think that
> > this forced change is an excellent incentive to review older
> > packages.
> Right. I have the exact opposite view: why compile a c++ project
> using c++11 flags while it was written for c++98...

Like I pointed out I think it is somewhat the same like with new
compilers: New compilers interpret the standard more strict, optimize
differently, and hence, we get build failures and test failures that we
need to fix. The same it is when moving from one standard to the next. 

You also consider that upstream is active and willing to migrate from
> c++98 toward c++11 (for example), I had the exact opposite example in
> mind.
I think nobody would object if you set the flag to -std=c++98 for a
certain package, especially if upstream is dead or unwilling to move to
a newer standard, but I wouldn't want to see it as the default.

> > I think we should strife for all packages using the
> > same C++ standard, and this should be the default of the currently
> > used C++ compiler. Forcing a lower standard on a package as a
> > maintainer I would consider only as a (temporal) workaround to fix
> > RC bugs, and preferable only for leaf packages.
> I do not see you point clearly. Let me rephrase it then: You would
> like to see no explicit -std=c++ in the build logs, so as to
> guarantee we always compile a c++ project using whatever default c++
> standard is being used by the current gcc version. Is this a correct
> rephrasing ?

I wouldn't mind, though, if there was some output from the compiler
that indicates what standard was used to compile a package, but that's
different from setting a standard explicitly. 


Reply to: