This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: C++11 (abridged version)
- From: Keith Seitz <keiths at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>, GDB Patches <gdb-patches at sourceware dot org>
- Date: Tue, 25 Oct 2016 13:29:19 -0700
- Subject: Re: C++11 (abridged version)
- Authentication-results: sourceware.org; auth=none
- References: <4300d24a-8711-c5de-79ce-7c530162288c@redhat.com>
Hi, Pedro,
I'm normally a "go with the flow" kind of person, and I've pretty much
had my head buried in the compile "sand," but I felt this topic
important enough to say something -- even if it has already been said.
TL;DR: I'm *all* for moving directly to C++11. I'm already using quite a
bit of it on C++ Compile.
On 10/20/2016 10:07 AM, Pedro Alves wrote:
> A large discussion around that patch followed [1], circling around a
> few related points:
>
> #1 - whether we should be reimplementing C++11 features.
>
Developers will undoubtedly find future standard library (or boost)
concepts, algorithms, etc useful now. Sometimes *very* useful.
std::unique_ptr (and I'd argue shared_ptr) is such a case we are seeing
today.
A requirement to maintain some backward-compatibility
(compiler-longevity?) necessarily leads to implementing some of the
newer, highly-desirable/beneficial library features ourselves. I don't
think this is an uncommon practice.
For me this C++11 "now" decision arises from the realization that C++11
is so much more useful that we might as well simply jump straight to
using it. It contains a handful of concepts that would be non-trivial or
perhaps even impossible to implement outside direct compiler support,
e.g., "auto", lambda functions, ...
While I'm no C++ guru, I don't think I would be alone in saying that
C++11 is the language specification C++ should have had years ago.
> #2 - whether we should be taking advantage of C++11 features when
> available, provided we have C++03 fully functional fallbacks in
> place. (and then generically, $version+1 features provided we
> have $version fallbacks.)
I'm generally fine with this. Again it seems a "necessary evil."
However, there is one concern I have, and the recent unique_ptr patch
exemplifies this. We now have a "unique_ptr." In fact, when using a
real C++11 compiler, gdb_unique_ptr.h will actually just alias a real
C++11 std::unique_ptr to gdb::unique_ptr.
Alas,
> - Putting gdb::unique_ptr in standard containers is not supported,
> since C++03 containers are not move-aware (and our emulation
> relies on copy actually moving).
The comment above shows that while the two are similarly named,
gdb::unique_ptr isn't yet really a real unique_ptr. However, for
developers like me who do use a C++11-compliant compiler, that's one
hidden gotcha waiting to be discovered.
Fortunately, I read the sources and discovered this before I used
unique_ptr in containers on the c++compile branch. I'm (mildly)
concerned that this could too easily lead to yet-another "our own
dialect" of C++(11) scenario(s).
Of course, it is *far* too early to make any concrete assertions about
this. The code has only been in the repository one week.
> #3 - whether we should instead switch to require a C++11 compiler
>
We gotta start somewhere, and IMO, C++11 is *by far* the best "safe"
place to do so.
> #4 - if so, then what is the policy to accept the next standard
> versions going forward.
I don't know how comfortable I am with such black-and-white rules, but I
think/hope that maintainers remain *flexible* about decisions like this.
Do what is "right" when it is "right." [That's not a "rule," per se, but
what I'd like the "spirit" of the rule to be.]
I think your offering on this policy indicates that you and I are in
agreement.
I'm already using C++11 features, and I am absolutely in favor of moving
directly to C++11.
TL;SW*
Keith
* Too Long; Stopped Writing :-)