Re: C++11 (abridged version)

[Keith Seitz <keiths at redhat dot 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 :-)