This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH 1/3] Introduce gdb::unique_ptr
> Date: Tue, 11 Oct 2016 15:23:46 -0400
> From: Simon Marchi <email@example.com>
> Cc: Pedro Alves <firstname.lastname@example.org>, email@example.com,
> firstname.lastname@example.org, email@example.com
> 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
No, it wasn't: warnings don't affect code at all. This suggestion