This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA 09/22] Remove make_cleanup_restore_current_ui
> 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".