Re: Go C++11?

Luis Machado
2016-10-19T18:02:55Z

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:
>>>> Cc: tom@tromey.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org
>>
>>>> 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
> updating.
>
> Sooo.... Shall we proceed with the straw man proposal and
> apply the patches at [2] (enable -std=gnu+11 on gcc >= 4.8)?
>
> [1] - https://sourceware.org/ml/gdb-patches/2016-10/msg00496.html
> [2] - https://sourceware.org/ml/gdb-patches/2016-10/msg00336.html
>
> 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.