Re: [RFA 09/22] Remove make_cleanup_restore_current_ui

[Eli Zaretskii <eliz@gnu.org>]

> Cc: tom@tromey.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org
> From: Pedro Alves <palves@redhat.com>
> Date: Thu, 13 Oct 2016 15:26:07 +0100
> 
> On 10/13/2016 02:52 PM, Eli Zaretskii wrote:
> 
> > Since I'm still unclear what is the oldest C++ standard we want to
> > support, I cannot decide whether I agree or disagree.  Is the version
> > of the C++ standard we support C++03 or C++11?  My comment assumed
> > that it was C++11.
> 
> It was decided in 2014 that we'd target C++03.  We have not decided
> yet to _require_ C++11.

Then that comment is not yet relevant.  But then I think we should not
use C++11 code in GDB.

> >> I'll give you more examples of why I think forbidding C++11 completely
> >> is short sighted.
> > 
> > Thanks, but that kind of arguments completely misses the point.  You
> > don't need to convince me that a later standard is better than the
> > previous ones.  The issue at hand is whether we should write code that
> > targets more than a single language standard, where these standards
> > aren't compatible.  I think we shouldn't.
> 
> They are not incompatible.  C++03 code compiles with a C++11 compiler
> just fine.

Granted, I meant the other way around: use code that a C++11 compiler
will compile, but not a C++03 compiler.

> > The code obfuscation is very significant.  Of course, as long as you
> > don't look into the gnulib headers, you don't care, but in this case
> > you propose to have all those shims in our sources, in plain sight.
> 
> Yes, "all those shims".  One file.  And then cleaner code in thousands
> of uses of the shim throughout the codebase.  None of that
> shim-using code needs to know what version of the standard is
> being targeted.  Take a look at patch #3 from the gdb::unique_ptr
> series, and see for yourself.
> 
> So I'll take that tradeoff, yes.

Is this a one-time tradeoff, for this single patch?  Or is this a
policy?  In the former case, I have no objections.  In the latter
case, the "one file" argument doesn't apply.

> >>> that means maintenance burden 
> >>
> >> For whom?  _I'm_ willing to maintain this code.
> > 
> > Are you saying that no one else will be allowed to modify the code
> > which has 2 branches, one for C++03, the other for C++11?  I'm betting
> > you aren't saying that, 
> 
> Of course not.
> 
> > and so this is a burden for all of us, not just for you.  
> 
> You're automatically assuming it's a burden.  I believe that's
> false.

It should be clear and agreed by all that maintaining two
implementations for a single feature is more work than maintaining
just one.

> >> It's not rocket science code.
> > 
> > Today it isn't.  I'm not talking about this particular patch, I'm
> > talking about this policy in general.  As do you, I suppose: you
> > aren't just asking for agreement about using C++11 features in this
> > single case, right?
> 
> I'm talking about adding a small utility that is going to be used 
> extensively throughout the codebase.  A smart pointer is a central widget.
> That mine was modeled on a C++11 feature should be seen as
> a _good_ thing.  The std::unique_ptr was so good that it made it
> to the standard.  Not a small feat.  Bonus.  Once we move on to C++11
> for real (I don't know when), then there's one less API to learn.

And I'm again asking whether this is about this single patch, or about
a more general policy.  I assume that it's the latter, in which case
we are not talking about a single small utility, we are talking about
all the code that will be in the future admitted to GDB with the same
premise.  It is the policy that I object to, not a single exception.

> >> Several others have said they think this is a good idea.  I've even
> >> ran this idea through the libstdc++ maintainer in person at the Cauldron.
> >> Trevor said he wants to do this in gcc as well.
> > 
> > I just wanted to voice my opposition, that's all.  I don't have to
> > give up just because a few others think otherwise.  Right?
> 
> Of course.  The problem is that your opinion is interpreted as
> a hard blocker.  The result is stalling.

If there are no more convincing arguments, then a usual way out of
stalling is to find some compromise.  Is that possible in this case?

> >> If redirecting to C++11 std::unique_ptr turns out to cause trouble, or
> >> I'm hit by a bus, then it's trivial to remove that redirection.  All it
> >> takes is remove a handful of lines of code guarded with
> >> #if __cplusplus >= 201103 to always go through the fallback implementation.
> > 
> > Once again, it's not just this single patch that bothers me.  Once we
> > have enough of these #if's, removing them is not necessarily a trivial
> 
> And not "not necessarily" either...  This just looks like fear of
> the unknown, I'm afraid.

What exactly is unknown here?  It should be clear to anyone that more
of such patches, with separate implementations for C++11 and C++03,
will come soon enough.  What reason do you have to think they won't?
After all, C++11 is so much better than C++03, right?

> > matter, especially when most of the builds, perhaps even all of them,
> > have been using the C++11 code path all the time, and the other one
> > has simply bitrotted.
> 
> As I've said before, we can make use of the buildbot for that.
> If the fallback code breaks, you get an immediate email notification.

If someone sets it up to build both with and without C++11, yes.
A.k.a. "maintenance burden".