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

[Pedro Alves <palves at redhat dot com>]

On 10/11/2016 07:36 PM, Eli Zaretskii wrote:

> As long as we stay with C++11, I have no problem (although it does
> look like a huge jump, which we perhaps should have taken more slowly,
> and stay with C++03 for now).  My problem begins where we will in a
> few months jump so easily to C++14 and whatever else is after that.  I
> see no reason not to fear this, do you?

I see no reason to fear this at all.  Yes, I think it'd be great to be able to
use C++14.  It's still C++, but with extra features that make our lives
easier.  No questions there, IMO.  The impediment would be _compiler availability_.
The reason you don't have to fear this is that in a few months, C++14 compiler
availability will not really have changed much.  In a few years, it'll
be likely that every 4-year-old-or-some-such-by-then distro will have
a C++14 compiler handy.  And likely so will you.  But maybe someone
brings up the topic then and we'll still decide it's not worth to
require C++14 anyway.  We'll surely reevaluate and figure out what
is going to be reasonable _then_.

> Where are the rules and decisions that we won't?

What sort of rules are you expecting?

> 
>> 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.
> 
> Please don't forget that you look at these problems from the POV of
> someone who always have the newest tools available. 

That's plain false.  I've been asked about "why not C++11" many times
recently, and I've always said that we likely wouldn't be able to
assume that C++11 compilers were readily available sufficiently yet.
There are examples of that on this list just recently, even.

I've even had heated discussions internally, fencing off from C++11
even, exactly due to concern of causing too much inconvenience on
people!

> I'm trying to
> keep these decisions in their proper perspective by taking a POV of
> someone whose tools are one or 2 major GCC releases older.

And that's the perspective I'm taking as well!  My system compiler is
gcc 5.3, for example.  And as I've said several times already, we're
talking about gcc 4.8, not gcc 7.  I don't understand why you keep
bringing up that point.

> 
>>> 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.
> 
> I didn't think there were a conspiracy.  But that doesn't help, does
> it?  

I guess it helps as much as suggesting that we'll suddenly
require 6.x or 7.x, as if we'd do that without considering
community consensus or doing a reasonable evaluation of
general availability / convenience.  That sounds borderline
insulting, even, but I know that you don't mean that.

> Such slippery slopes are known human tendency, the only way to
> avoid that is not to step on the slope in the first place.

I want to climb the slope.  That's the only way out, and I don't
want to stay.  But I'll take my time.  If we go slow, I won't slip.

> 
>>> 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.
> 
> I think we need to document that before we more forward.  Otherwise we
> won't know whether we are moving forward or not, and won't know to
> stop and think a bit before we do.
> 
>> 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.
> 
> Then maybe we shouldn't make that huge jump, not just yet.  It was
> never discussed seriously, AFAIK.

Well, we're discussing it right now, in several threads, even.

By "huge", I meant that having access to C++11 would be super
awesome.  It makes it possible to do things in way less "magic"
ways.  C++03 requires lots of weird contortions.  So if we
could use C++11, you'd see _less_ complex C++!  C++14 is an
improvement over C++11, but the improvement is not so much
as the improvement from C++03 to C++11.  That's what I meant.

> 
>>>> 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.
> 
> That's not how I read your messages.  Apologies for my
> misunderstanding, but I can show you how your words actually made that
> sound as if you were.

Please do.  I'd love to learn to be clearer.

> 
>> 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.
> 
> I don't think it's a good analogy.  You are not talking about warning
> switches, are you?

I think it's an excellent analogy, actually.  Of course I'm not talking
about warning switches -- it's an _analogy_.  I'm talking about something
that has the _exact same effect_.  A new default warning on GCC often triggers
new build errors, because we use -Werror.  See all the
recent -Wimplicit-fallthrough on this list and on binutils@.
Exact same thing.  Newer GCCs catch more problems.  That's exactly
what I'm proposing with the C++11-only bits in this patch.

> 
>> 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.
> 
> Where does it say that we should require C++11?  Or any specific
> version of the C++ standard, for that matter?  AFAIR, this was never
> discussed.

Eli, the require-C++11 discussion was not this particular subthread.
Look back to what you're replying to.  The context is, you argued:

>> a massive rewrite of GDB in complex C++.

I pointed out that the rewrites going on are not that complex,
they're basic C++.

You then said:

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

And I pointed out that it's not true that these "complex C++"
changes that you were referring to (the existing patches
pending on the lists) have not been planned.

> 
>>> 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!
> 
> I'd still be happier if you were not mistaken.

You yourself said that you have gcc 5.x available.  I don't really
understand why we're still arguing about this.

Thanks,
Pedro Alves