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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 11 Oct 2016 15:23:46 -0400
> From: Simon Marchi <simon.marchi@polymtl.ca>
> Cc: Pedro Alves <palves@redhat.com>, brobecker@adacore.com,
>  markus.t.metzger@intel.com, gdb-patches@sourceware.org
> 
> C++03 has been around for long enough that we can safely migrate to that 
> (whereas it has value or not is another debate, although I think Pedro 
> showed clearly that it has), without leaving many users behind.  C++11 
> comes with some nice features in its standard library, such as 
> std::unique_ptr.  std::unique_ptr has some improvements over the old 
> std::auto_ptr, which was too easy to misuse.  However, I think we all 
> agree that C++11 would be a too aggressive change, and will still be for 
> some time.

Then why was there talk to use -std=gnu++11?

> What Pedro chose to do is to create gdb::unique_ptr, our home-made 
> version of std::unique_ptr.  When building with a C++03 compiler, the 
> hand-written version of the code is chosen and it works (see the #if 
> __cplusplus >= 201103).  However, it's possible to misuse it, the same 
> way as it was possible to misuse std::auto_ptr (because of missing 
> features in C++03 vs C++11 IIUC).  If you happen to build with a C++11 
> compiler, instead of choosing the hand-written version, gdb::unique_ptr 
> is more or less an alias for std::unique_ptr.  So if there is a place in 
> the code that is misusing it, the build will fail and either buildbot or 
> another developer will let us know promptly.
> 
> So it's not that the code is built in a way which requires C++11, it's 
> built in a way that if you use C++11, you get the benefits of the newer 
> checking mechanisms, while still being able to build with a C++03 
> compiler.  IMO it's the best of both worlds.  Actually, it's the same 
> idea as gnulib, where we fill the gaps of the lacking platforms, rather 
> than choosing a low common denominator.

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.  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.

> The warning analogy was perhaps not clearly expressed but I think it was 
> good.

No, it wasn't: warnings don't affect code at all.  This suggestion
clearly will.