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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: brobecker@adacore.com, gdb-patches@sourceware.org,
>         jan.kratochvil@redhat.com, simon.marchi@ericsson.com
> From: Pedro Alves <palves@redhat.com>
> Date: Wed, 12 Oct 2016 11:11:50 +0100
> 
> >   . Should we start using C++11 features in GDB?
> 
> I would hope that no one would suggest that we shouldn't use
> C++11 features just because they like C++03 better than C++11.
> That would make no sense.

It would make perfect sense if we decide to require a version of GCC
older than 4.8.1 as a prerequisite for building GDB.

> In my mind, the only reason you'd not use C++11 over C++03
> is simply because you couldn't because you don't have a
> compiler that supports it.  IMO, at this point, the number
> of systems that don't have a C++11 compiler handy AND where
> you'd absolutely need to build a new GDB is sufficiently small that
> the desire to use C++11 features overwhelms the inconvenience
> of having to build a new compiler first, on those specific cases.

These are qualitative arguments.  We need a quantitative criteria for
when to raise the bar for the minimum supported language standard.
Such a criterion could be the number of years since the release of the
GCC version that fully supports that standard.  If this is an
acceptable criterion, can we talk about the number of years we would
like to set up as the quantitative parameter here?  Can we then commit
ourselves to upholding that criterion for the observable future?

> Many of the larger projects around the free software community
> require C++11 nowadays.

And many still support C90.  E.g., Emacs started requiring C99 in
version 25.1, released just a month ago.  GNU Make still supports C90,
as does Gawk.  So I don't think this is a useful argument, because
there are examples either way.

> But even if we don't _require_ C++11, IMO, yes, we should
> still use select C++11 features when available, in implementation 
> details of gdb's general utilities, when they add extra safety or
> efficiency that is simply not possible in C++03.

If these features are supported by whatever versions of the compiler
we decide to require, I agree.

> TBC, I would reject patches that added:
> 
> #if cxx11
> ...
> #else
> ...
> #endif
> 
> sprinkled around the codebase in non-utility code.

Agreed.

> >   . Should we document these decisions and also decide to abide by
> >     them for some reasonably long stretch of time?
> 
> Sure, we should document the decisions.  But I see no point in locking
> ourselves to past decisions on a timed basis.  Past decisions should
> be reevaluated simply when they longer make sense.  I.e.,
> apply past reasoning to current reality and see if the same answer 
> comes out.

"No longer make sense" is again too vague to be efficient in
preventing arguments like this one.  We should decide on firm
principles and stick to them.  Even if that means we will keep the bar
lower for longer than absolutely necessary (and it doesn't have to
mean that), that's hardly a catastrophe.