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

[Eli Zaretskii <eliz@gnu.org>]

> From: "Metzger, Markus T" <markus.t.metzger@intel.com>
> CC: "brobecker@adacore.com" <brobecker@adacore.com>,
> 	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>, "Jan Kratochvil
>  (jan.kratochvil@redhat.com)" <jan.kratochvil@redhat.com>, Simon Marchi
> 	<simon.marchi@ericsson.com>
> Date: Wed, 12 Oct 2016 08:11:44 +0000
> 
> I think we got hung up on the perceived requirement of having to build
> your own GCC.  The discussion got a bit too abstract and mentioning GCC 6
> as the first to default to C++11 may have been confusing in the heat of the
> discussion as "GCC 6 defaults to C++11" may have been misread as "C++11
> requires GCC 6".

I don't think that's what happened.  In my interpretation, there are
simply several issues intertwined in this discussion (which probably
adds to confusion):

  . Should we start using C++11 features in GDB?
  . If the answer to the above is YES, then should we require a C++11
    capable compiler as a prerequisite, or should we provide fallback
    code for compilers that don't support C++11, not even with a
    non-default command-line option?
  . Should we document these decisions and also decide to abide by
    them for some reasonably long stretch of time?

> A simple and pragmatic solution would be a patch to add -std=c++11
> to GDB's compiler options.  Pedro already mentioned it but I'm afraid it
> got lost.
> 
> This documents the required language version and also prevents people
> from accidentally using C++14/17/?? features and not noticing it until one of
> the buildbot builders complained.
> 
> I don't think that requiring C++11 is entirely unreasonable and IMHO
> preferable to back-porting standard library features.
> 
> Should I be wrong and C++11 is really not doable, I like Pedro's patch
> for giving the direction towards C++11.  I would still add a compiler option
> to enforce C++03 for the above reasons.

Here are my opinions on the above 3 issues:

  . I think we should stay with C++03 for at least a year.  Jumping
    from C90 to C++11 sounds too huge a jump.  Setting the bar on
    C++03 would mean we still allow GCC 4.3, AFAIU, which was released
    in 2008.  That's less than 10 years from today, so not too old
    IMO.  We could also decide to switch to C99-level compilers, which
    AFAIU means GCC 4.5, released in 2010.  (GCC 4.8.1, with its C++11
    support, was released in 2013.)

  . Whatever standard we decide to aim, we should require a compiler
    that is capable of supporting that standard, whether with or
    without optional command-line switches, and we should use those
    switches if necessary (detected by configure) during the build.
    We should not provide any fallback code for compilers that don't
    support the standard we decide to use -- such fallback code is
    just maintenance headache and in the long run means code that is
    rarely if ever tested.

  . We should clearly document these decisions, and abide by them.
    Resetting the bar to a higher standard should IMO be based on the
    number of years since the release of the first GCC that supports
    that standard.  The number of years we would like to aim for
    should also be a documented decision.