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

[Pedro Alves <palves@redhat.com>]

On 10/11/2016 05:57 PM, Eli Zaretskii wrote:

>> That's a misunderstanding.  Full C++11 support is available
>> in gcc 4.8 already.
> 
> Yes, I know.  I'm just envisioning that once we require to build GCC,
> we will soon require a new enough version of it.  Like Joel says:

That still sounds like a misunderstanding, because we're not
requiring that you build GCC.  We're talking about requiring
C++11 support.  There's a difference.  If you don't have a compiler
that supports C++11, _then_ you'd have to build one.  That is, we're
mainly talking about the trade off between getting access to C++11
and how that would improve the codebase and maintainability vs
convenience of getting a new gdb built on an older system with an
old system compiler.

> 
>> We've already made a huge requirement jump; let's just do it right
>> all the way. That increment doesn't seem all that significant
>> compared to requiring a C++ compiler.
> 
> I see where it's going, and I don't like it.  We will make it hard on
> users to build GDB.  Just 7 months ago all you needed was a C90
> compiler, and look where we are now.

There's no sekrit conspiracy here.  We all want gdb to succeed, don't we?
All we're talking about is being able to use features that our
friends on the gcc side have been working hard at making available to
users, because well, they're actually useful.  Of course there's a
balance between wanting to use the latest features, and waiting until
compiler availability is reasonably widespread.

> 
>> I believe it's easy to find binary mingw gcc's of (at least) that
>> vintage easily, for both mingw and mingw-64.
> 
> If we stay with 4.8 for long enough, I have no problem.  But we must
> record this decision somewhere and stick to it, because otherwise it
> will be one more domino to fall, and soon enough.

Yes, of course if we move forward with a requirement change we'll
document it.  It'll naturally end up reevaluated at some point, maybe
years from now.  The jump from C++03 -> C++11 is _huge_.  C++11 -> C++14
not that much.

> 
>> I don't expect anyone to _have_ to build any mingw compiler to be able
>> to build gdb for mingw.  
> 
> If you suddenly require 6.x or 7.x, they will have no choice.

Well, that's (an unintended, no doubt) strawman, because no one is
suggesting that.

> 
>> It's just that gcc 6.x is the first version that has switched
>> the _default_ mode for C++ to -std=gnu++14.  So until someone writes a
>> patch that make gdb's build system enable C++11 support with gcc < 6,
>> then the C++11-only code in the gdb::unique_ptr patch that I'm proposing
>> will only be active with gcc 6.1 onward.  But really I'm not
>> proposing to _require_ 6.x at all.
> 
> How's above not requiring 6.x?  "Until someone writes a patch that
> make gdb's build system enable C++11 support with gcc < 6" one must
> have 6.x, or some code will not work or be unavailable for them,
> right?  (And isn't there confusion between gnu++14 and C++11?)

The code still works with older gccs, and just as efficiently.

I'll make an analogy.  Think of it as if GCC 6.x enabled some
useful warning flag by default that used to be disabled by default.
Until someone enables the warning on older GCCs that support it, some
styles of code we don't want to allow compile successfully, while with
6.x, we get a hard error due to -Werror.  So code smells that might get
into the tree because they were only tested against an old GCC will
will be caught quickly by whoever next builds gdb with a newer GCC that
enables the warning by default.

The C++11-only code in question that I'm proposing is just what enables
the "warning".  The C++03 version of the same code does not trigger
any "warning", but it still runs.

> Maybe you are 110% right; all I know is that these C++ surprises
> started pouring on us with increasing rate without any prior
> discussion, that's all.

First, it's not true that these C++ changes have not been planned.
They've been part of the plan ever since the very beginning.  See
here, step 5 of the original version of the plan I originally
circulated in 2014:

  https://sourceware.org/gdb/wiki/cxx-conversion?action=recall&rev=1

Current version is here:

  https://sourceware.org/gdb/wiki/cxx-conversion#Transition_plan

Note the not-done-yet bullet points in step 8 (step 5 in rev 1).
That's exactly what's going on right now.

I've also discussed the next steps of the transition on my Cauldron
talk this September, though that was indeed recent:

 https://gcc.gnu.org/wiki/cauldron2016#Slides.2C_Videos_and_Notes

Still, that's just rehashing what was already planned.

But truth be told, I wasn't expecting patches to appear so fast
either!  Most of my C++ patches had been on the "enablement" form
thus far, with the bigger ones in sourceware branches.  But if people
are willing to spend the effort to contributing nice C++ conversion
series (which is awesome, IMO), that means they care significantly
about the health of the codebase and the project, and thus I'll try
to review those patches quickly, in order to keep the contributor's
motivation alive.

So I see the recent rush as a _good_ thing.

> 
> But I don't want to argue about C++, that was just an example of a
> slippery slope similar to what I fear will happen once we require a
> new enough GCC to be able to compile GDB.  I think that would be a bad
> mistake.

Again, no one's proposed that.  Heck, until today I was under the
impression that gcc 4.8 was too new and had assumed proposing to require
that for C++11 would be out of question.  But I'm very happy to
learn that I've been mistaken!

Thanks,
Pedro Alves