This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Go C++11?

On 10/17/2016 06:43 PM, Pedro Alves wrote:
On 10/13/2016 04:43 PM, Pedro Alves wrote:
On 10/13/2016 04:19 PM, Eli Zaretskii wrote:

All I know right now that we sorely need an owning smart pointer.
And for this particular case, I think it makes a ton of sense to go
dual dialect.

But if we agree to require C++11 starting from now, you can go ahead
with your patch, and don't even need the other dialect.  So this
sounds like a win-win solution to me.

Well, that'd be perfect.

But as I mentioned elsewhere, I'd prefer to take a staged approach
to C++11.  I.e., have a fallback plan.  My shim would actually _help_
with that.  So the plan would span a few weeks, and it'd be:

#1 - get gdb::unique_ptr in

#2 - start using unique_ptr throughout (there's a ton of work
     to do here, and it go on in parallel with the remainder
     of the plan.)

#3 - install the patch that switches C++11 on if the compiler supports it.
     The one I sent yesterday.

#4 - see if that causes problems.  fix problems.  maybe revert patch
     from step #3 if problems are hard to solve quickly.

#5 - flip to consider C++11 mandatory.  Make configure error out
     if no C++11 compiler is found.

#6 - see what workflows break (e.g., see if we need to do anything
     with some buildslaves.

#6.a - if $problem, revert patch from step #5.  fix whatever workflows,
       and goto #5.

#7 - otherwise, after some period, start using C++11 in full.
     Remove the shim and do s/gdb::unique_ptr/std::unique_ptr/g
     throughout the code base.

All the while between #1 and #7, we can progressively convert
cleanups to use gdb::unique_ptr.  Ie., we'd pipeline/paralyze
the work.

So from the analysis I did at [1] it seems like we're actually
clear from the buildslave's side on requiring C++11.  I thought
it take longer to update the buildslaves, but MarkW was quick
and there doesn't seem to be other buildslaves that need

Sooo....  Shall we proceed with the straw man proposal and
apply the patches at [2] (enable -std=gnu+11 on gcc >= 4.8)?

 [1] -
 [2] -

Do people feel this hasn't been sufficiently discussed?

If we can do this now, I'll happily drop my shim in favor of
jumping to C++11 quicker!  Maybe it'll find a home in gcc.  :-)

I'd love to hear feedback.

I personally feel this hasn't been discussed much, but honestly it doesn't feel like discussion is going to change anything here other than create clashes of ideas. :-)

I've seen this go from "You got it wrong. We're not going to move to C++11" to "So, shall we move now?" rather quickly. Nothing showed up in gdb@ either.

Since we're already moving things quickly, we should probably discuss a policy to accept the next standard version and follow that from now on.

My $0.02.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]