Re: [RFA 09/22] Remove make_cleanup_restore_current_ui

[Pedro Alves <palves@redhat.com>]

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.

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

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

Yes, I do.

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

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

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

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

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

Many, many, many, free software projects, small and large, went
through that exercise.  It's known territory, we can learn
from their experience, and we know that it's quite doable.

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

;-)

Thanks,
Pedro Alves