Re: [RFA 09/22] Remove make_cleanup_restore_current_ui

[Eli Zaretskii <eliz at gnu dot org>]

> Cc: tom@tromey.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org
> From: Pedro Alves <palves@redhat.com>
> Date: Thu, 13 Oct 2016 11:16:26 +0100
> 
> On 10/13/2016 07:11 AM, Eli Zaretskii wrote:
> >> Cc: Simon Marchi <simon.marchi@polymtl.ca>, gdb-patches@sourceware.org
> >> From: Pedro Alves <palves@redhat.com>
> >> Date: Thu, 13 Oct 2016 02:28:44 +0100
> >>
> >> Yeah, sounds right.  I was trying get the gdb::unique_ptr in, in order
> >> to unblock the cases I suggested you use unique_ptr, but I'm a bit
> >> confused on what to do about it now...  I _think_ people are generally
> >> OK with it.  There was some opposition, but I'm not sure anymore
> >> whether it still exists.  C++11 is now on the table, but maybe a
> >> staged approach (enable C++11 while supporting C++03 too for a while,
> >> to catch issues) would make sense anyway.
> > 
> > I still think we shouldn't have workarounds for versions of the
> > standard older than what we want to support.
> 
> That is not what the patch does...  

I wasn't referring to the patch, I was referring to the quoted part of
your message, specifically to this:

> >> C++11 is now on the table, but maybe a staged approach (enable
> >> C++11 while supporting C++03 too for a while, to catch issues)
> >> would make sense anyway.

> So again:
> 
> > I still think we shouldn't have workarounds for versions of the
> > standard older than what we want to support.
> 
> there's no workaround for versions older than what we want to support
> at all.

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.

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

> > Supporting more than one standard means we will have rarely used code
> > that is almost never tested, and that means maintenance burden 
> 
> That same argument could be applied to gnulib.  Or the many HAVE_FOO's
> in the code base.  We rely on gnulib's reimplementation of the whole
> printf family of functions if the compiler doesn't support it properly
> for example!

I did apply it to gnulib at the time, but was voted down.

Do you seriously consider the gnulib solution a good one?  I don't.
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.

> > 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, and so this is a burden for all of us, not
just for you.  And that is even before we consider the "bus issue".

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

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

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

> > which
> > threaten to undo at least some part of the benefits you aspire to
> > achieve by moving to C++ in general and to a new enough C++ standard
> > in particular.
> 
> I don't understand what this is trying to say.

The move to C++ was supposed to make the maintenance easier, right?
I'm saying that targeting more than a single language standard makes
maintenance harder, so it works against the purpose of the move.

> And no, I'm not planning on getting hit by a bus.  :-)

Who is?