Re: [PATCH 1/3] Introduce gdb::unique_ptr

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 11 Oct 2016 17:28:24 -0400
> From: Simon Marchi <simon.marchi@polymtl.ca>
> Cc: palves@redhat.com, brobecker@adacore.com, markus.t.metzger@intel.com,
>  gdb-patches@sourceware.org
> 
> On 2016-10-11 16:54, Eli Zaretskii wrote:
> > Then why was there talk to use -std=gnu++11?
> 
> For those compilers that support C++11, but default to C++03.  If the 
> feature is present and using it provides use with better error-checking, 
> why not use it?

You are contradicting yourself.  Previously, you said:

> However, I think we all agree that C++11 would be a too aggressive
> change, and will still be for some time.

Now you are saying that we _should_ use C++11?  Do you see how
confusing all this is?  I cannot even figure out what is it that
people are arguing for or against.

> > That's not "stick to C++03" in my book.  Sticking to C++03 means not
> > writing any code that requires a later standard at all.
> 
> That's your interpretation.  I prefer to interpret it as compilable with 
> a C++03 compiler, with no significant difference in the resulting 
> behaviour.
> 
> > Exactly like
> > we did when we required C90, but not C99: we had no code written for
> > C99 compilers, #ifdef'ed away for C90 compilers.  Everything was C90.
> 
> Maybe because there wasn't a need or reason to do so?  In this case, 
> there appears to be some value doing it.  Do you question the fact that 
> it brings value at all, or that that value is not worth the extra 
> complexity?

I question the honesty of the decision not to switch to standards
supported only by recent versions of GCC.  There's always a shining
new version of the standards out there, which is normally much better
than the previous ones.  By that logic, we should switch to the latest
version of standard C++ the moment it appears in draft, because it
definitely brings some significant value.

> I am sure nobody wants to see the whole code base sprinkled with such 
> #ifs.  But here it's isolated in a file that we'll almost never touch 
> again, and which will significantly improve the rest of the code base, 
> with which we work with daily.

Once admitted into the sources and allowed as acceptable practice,
this will never remain limited to a single file.  Let's not be naïve.