C++11 (abridged version)

C++11 (abridged version)

[Pedro Alves]

Since some felt that C++11 might have not been discussed sufficiently,
I thought I'd try to summarize the recent discussions, and present
my view condensed in a single email.  Please read until the
end before replying. :-)

On C++11
--------

Now that gdb 7.12 is out, master has switched to requiring a C++03
compiler.  The original plan, which we have been following, was to
stay within C++03:

  https://sourceware.org/gdb/wiki/cxx-conversion

Over the past weeks, patches actually making use of C++ started
appearing on the lists, and the subject of how C++11 would simplify
things came up, multiple times.

A couple weeks ago, I sent a patch to add an owning smart pointer to
GDB.  I chose to model the interface on C++11's std::unique_ptr.  For
that reason, our version is called gdb::unique_ptr.  My patch went a
step further, and made gdb::unique_ptr be an alias for std::unique_ptr
if compiled with a C++11 compiler.  See the version that landed in the
tree at <https://sourceware.org/ml/gdb-patches/2016-10/msg00506.html>,
which contains the clearest commit log / introduction.

A large discussion around that patch followed [1], circling around a
few related points:

#1 - whether we should be reimplementing C++11 features.

#2 - whether we should be taking advantage of C++11 features when
     available, provided we have C++03 fully functional fallbacks in
     place.  (and then generically, $version+1 features provided we
     have $version fallbacks.)

#3 - whether we should instead switch to require a C++11 compiler

#4 - if so, then what is the policy to accept the next standard
     versions going forward.

I'll expand on each of those points below, presenting my opinions
and suggested way forward.

On #1, my opinion is yes.  It makes total sense IMO to model
APIs/features on what the standard ends up with, in order to ease
future transition to a newer standard requirement, and also to
leverage the learning and reference material found throughout the
internet, dedicated to standard C++.  That's assuming that the
standard APIs in question are a good fit for the use case in question,
of course.  Here I'm thinking of small utility routines, like
std::to_string, or some metaprogramming helpers (traits), and things
like that.  Aiming at designing APIs compatible with the standard
library algorithms should go without saying.

On #2, I think it depends.

Sprinkling random code throughout with #ifdef __cplusplus >= $ver
should be out of question.  I don't think anyone would seriously
propose that.

Cases like taking advantage of new keywords to catch problems at
compile time I think are no brainers.  For example C++11
final/override.  A similar case would be to take advantage of being
able to mark code as "constexpr".  Going forward, C++14 allows
constexpr in more cases, so even before requiring C++14, I could see
us adding a CONSTEXPR14 define that compiles out to nothing if the
compiler doesn't support it, just like the FINAL/OVERRIDE macros.  I
don't have a use case in mind, but if it appears, I don't think we
should prohibit it.  Yet another example would be C++17 attributes,
which are mostly the same as GCC's __attribute__, except standard.

Otherwise, if talking about standard library features, I think that if
the conditional compilation is done inside some central gdb utility
routine, and, it gives some great advantage, then I think yes.
Otherwise, no.

The case of using C++11's std::unique_ptr, which enforces move
semantics using rvalue references, and uses SFINAE to only allow safe
conversions (catching them at compile time), is an example of "great
advantage".  It would be possible to implement or closely emulate
these things in C++03, but it'd not be trivial code.  People were
already calling my unique_ptr "boost-like", even though it's actually
a very simple smart pointer.  Much simpler to punt on the
complications, and just rely on a real C++11 compiler to catch
problems at compile time.  I can't think of another example like
this though.  I think these cases must be evaluated on a case by
case basis, with the default being "don't do it".  The std::unique_ptr
case is special because an owning pointer will naturally be used
pervasively.

My opinion on #3 (should we require C++11 now), is yes.  C++11 is a
great step up from C++03, and being able to use it fully would result
in a more efficiency gdb, and would also allow simplifying things that
require ugly workarounds in C++03.  I.e., if you hate C++ and you think
it's messy, it may actually be that what you hate is C++03, and that you'd
actually like C++11 if you give it a chance.  E.g., rvalue references, efficient
move-aware containers (also allowing us to make containers "own" the containing
objects, resulting in even simpler code), template aliases, variadic templates,
etc. etc.  C++11 would avoid having to consider reimplementing basic utilities
like e.g., a type-safe hash table.  C++11 is also a _simpler_ language in a way,
as some ugly warts have been ironed out in the language (e.g., std::string
and contiguous buffer guarantees).


On #4 (policy for newer standard versions), as I've been saying many
times in the past week, I think that what matters is whether there's
reasonably widespread compiler availability, meaning the latest stable
releases of distributions include a compiler for the standard, or it's
easy to get one by installing some optional package.  If reasonably
available, then we should switch, and take advantage of the great work
our compiler and standards friends have been doing.  If OTOH we require
every GDB developer and integrator to build a compiler first before building
gdb, then that is too inconvenient and we shouldn't switch yet.  I
don't think, however, that the rarer use case of wanting to build a
new gdb on an old/ancient distro to debug programs built with an old
compiler should hold us back.  For those rarer cases, I think it's OK
if you'd need to build a compiler first.  Failing that, you can still
use remote debugging with new gdb on a separate machine against
old gdbserver on old machine.  Or failing even that, there's always
old gdb, which is not going away..

On GCC, full C++11 support started with GCC 4.8.  And, from the past
week's discussions, I think that it became clear that at least GCC 4.8
is easily available one way or another on (at least) the latest
stable release of all the major GNU/Linux distros.  BSDs have clang
versions available that support C++11 too, either as system compiler
or as a package in ports.  For Windows/mingw/mingw-w64, again there are
binaries easily available.  Etc.  In practice, most people are actually
building GDB with newer compilers even.  And, many have actually been
building GDB as as a C++14 program for a while, because GCC 6.1 switched
the default C++ dialect to C++14...

One related potential blocker that I saw was whether the buildslaves
in our buildbot were ready for the conversion.  As you can see in this
thread <https://sourceware.org/ml/gdb-patches/2016-10/msg00488.html>,
I believe we're now ready on that end too.

Going forward past C++11, since "reasonable availability" is not
quantifiable, Eli suggested the policy of

  "(...) waiting until the oldest compiler which supports that newer
  standard is at least 3 years old (like GCC 4.8.1 is today)."

And I agree with that.  (I'd prefix it with "at least".)  

Of course, even policies can be re-discussed later, so we shouldn't feel
trapped on past decisions, but, I think that that's a reasonable starting
guideline, and having it clearly written somewhere is more transparent,
which definitely a good thing in my view.

At this point, I find myself in an odd position --- several people
have been telling me offlist how they wanted C++11 like yesterday already.
There was support in last week's discussions as well.  OTOH, I'm not
sure whether I can assume that silence on the list means "go ahead".
So I think I'll need to call a bold move and say that if there are no
actual identified blockers, or if people reply to this email with
approval, I'm going to proceed with the straw man 'path toward
C++11' proposal at
<https://sourceware.org/ml/gdb-patches/2016-10/msg00381.html> real
soon.

[1] - most of the discussion happened in two threads here:

 - https://sourceware.org/ml/gdb-patches/2016-10/msg00223.html
 - https://sourceware.org/ml/gdb-patches/2016-10/msg00341.html

Thanks,
Pedro Alves

Re: C++11 (abridged version)

[Luis Machado]

On 10/20/2016 12:07 PM, Pedro Alves wrote:
> Since some felt that C++11 might have not been discussed sufficiently,
> I thought I'd try to summarize the recent discussions, and present
> my view condensed in a single email.  Please read until the
> end before replying. :-)
>
> On C++11
> --------
>
> Now that gdb 7.12 is out, master has switched to requiring a C++03
> compiler.  The original plan, which we have been following, was to
> stay within C++03:
>
>   https://sourceware.org/gdb/wiki/cxx-conversion
>
> Over the past weeks, patches actually making use of C++ started
> appearing on the lists, and the subject of how C++11 would simplify
> things came up, multiple times.
>
> A couple weeks ago, I sent a patch to add an owning smart pointer to
> GDB.  I chose to model the interface on C++11's std::unique_ptr.  For
> that reason, our version is called gdb::unique_ptr.  My patch went a
> step further, and made gdb::unique_ptr be an alias for std::unique_ptr
> if compiled with a C++11 compiler.  See the version that landed in the
> tree at <https://sourceware.org/ml/gdb-patches/2016-10/msg00506.html>,
> which contains the clearest commit log / introduction.
>
> A large discussion around that patch followed [1], circling around a
> few related points:
>
> #1 - whether we should be reimplementing C++11 features.
>
> #2 - whether we should be taking advantage of C++11 features when
>      available, provided we have C++03 fully functional fallbacks in
>      place.  (and then generically, $version+1 features provided we
>      have $version fallbacks.)
>
> #3 - whether we should instead switch to require a C++11 compiler
>
> #4 - if so, then what is the policy to accept the next standard
>      versions going forward.
>
> I'll expand on each of those points below, presenting my opinions
> and suggested way forward.
>
> On #1, my opinion is yes.  It makes total sense IMO to model
> APIs/features on what the standard ends up with, in order to ease
> future transition to a newer standard requirement, and also to
> leverage the learning and reference material found throughout the
> internet, dedicated to standard C++.  That's assuming that the
> standard APIs in question are a good fit for the use case in question,
> of course.  Here I'm thinking of small utility routines, like
> std::to_string, or some metaprogramming helpers (traits), and things
> like that.  Aiming at designing APIs compatible with the standard
> library algorithms should go without saying.
>
> On #2, I think it depends.
>
> Sprinkling random code throughout with #ifdef __cplusplus >= $ver
> should be out of question.  I don't think anyone would seriously
> propose that.
>
> Cases like taking advantage of new keywords to catch problems at
> compile time I think are no brainers.  For example C++11
> final/override.  A similar case would be to take advantage of being
> able to mark code as "constexpr".  Going forward, C++14 allows
> constexpr in more cases, so even before requiring C++14, I could see
> us adding a CONSTEXPR14 define that compiles out to nothing if the
> compiler doesn't support it, just like the FINAL/OVERRIDE macros.  I
> don't have a use case in mind, but if it appears, I don't think we
> should prohibit it.  Yet another example would be C++17 attributes,
> which are mostly the same as GCC's __attribute__, except standard.
>
> Otherwise, if talking about standard library features, I think that if
> the conditional compilation is done inside some central gdb utility
> routine, and, it gives some great advantage, then I think yes.
> Otherwise, no.
>
> The case of using C++11's std::unique_ptr, which enforces move
> semantics using rvalue references, and uses SFINAE to only allow safe
> conversions (catching them at compile time), is an example of "great
> advantage".  It would be possible to implement or closely emulate
> these things in C++03, but it'd not be trivial code.  People were
> already calling my unique_ptr "boost-like", even though it's actually
> a very simple smart pointer.  Much simpler to punt on the
> complications, and just rely on a real C++11 compiler to catch
> problems at compile time.  I can't think of another example like
> this though.  I think these cases must be evaluated on a case by
> case basis, with the default being "don't do it".  The std::unique_ptr
> case is special because an owning pointer will naturally be used
> pervasively.
>
> My opinion on #3 (should we require C++11 now), is yes.  C++11 is a
> great step up from C++03, and being able to use it fully would result
> in a more efficiency gdb, and would also allow simplifying things that
> require ugly workarounds in C++03.  I.e., if you hate C++ and you think
> it's messy, it may actually be that what you hate is C++03, and that you'd
> actually like C++11 if you give it a chance.  E.g., rvalue references, efficient
> move-aware containers (also allowing us to make containers "own" the containing
> objects, resulting in even simpler code), template aliases, variadic templates,
> etc. etc.  C++11 would avoid having to consider reimplementing basic utilities
> like e.g., a type-safe hash table.  C++11 is also a _simpler_ language in a way,
> as some ugly warts have been ironed out in the language (e.g., std::string
> and contiguous buffer guarantees).
>
>
> On #4 (policy for newer standard versions), as I've been saying many
> times in the past week, I think that what matters is whether there's
> reasonably widespread compiler availability, meaning the latest stable
> releases of distributions include a compiler for the standard, or it's
> easy to get one by installing some optional package.  If reasonably
> available, then we should switch, and take advantage of the great work
> our compiler and standards friends have been doing.  If OTOH we require
> every GDB developer and integrator to build a compiler first before building
> gdb, then that is too inconvenient and we shouldn't switch yet.  I
> don't think, however, that the rarer use case of wanting to build a
> new gdb on an old/ancient distro to debug programs built with an old
> compiler should hold us back.  For those rarer cases, I think it's OK
> if you'd need to build a compiler first.  Failing that, you can still
> use remote debugging with new gdb on a separate machine against
> old gdbserver on old machine.  Or failing even that, there's always
> old gdb, which is not going away..
>
> On GCC, full C++11 support started with GCC 4.8.  And, from the past
> week's discussions, I think that it became clear that at least GCC 4.8
> is easily available one way or another on (at least) the latest
> stable release of all the major GNU/Linux distros.  BSDs have clang
> versions available that support C++11 too, either as system compiler
> or as a package in ports.  For Windows/mingw/mingw-w64, again there are
> binaries easily available.  Etc.  In practice, most people are actually
> building GDB with newer compilers even.  And, many have actually been
> building GDB as as a C++14 program for a while, because GCC 6.1 switched
> the default C++ dialect to C++14...
>
> One related potential blocker that I saw was whether the buildslaves
> in our buildbot were ready for the conversion.  As you can see in this
> thread <https://sourceware.org/ml/gdb-patches/2016-10/msg00488.html>,
> I believe we're now ready on that end too.
>
> Going forward past C++11, since "reasonable availability" is not
> quantifiable, Eli suggested the policy of
>
>   "(...) waiting until the oldest compiler which supports that newer
>   standard is at least 3 years old (like GCC 4.8.1 is today)."
>
> And I agree with that.  (I'd prefix it with "at least".)
>
> Of course, even policies can be re-discussed later, so we shouldn't feel
> trapped on past decisions, but, I think that that's a reasonable starting
> guideline, and having it clearly written somewhere is more transparent,
> which definitely a good thing in my view.
>
> At this point, I find myself in an odd position --- several people
> have been telling me offlist how they wanted C++11 like yesterday already.
> There was support in last week's discussions as well.  OTOH, I'm not
> sure whether I can assume that silence on the list means "go ahead".
> So I think I'll need to call a bold move and say that if there are no
> actual identified blockers, or if people reply to this email with
> approval, I'm going to proceed with the straw man 'path toward
> C++11' proposal at
> <https://sourceware.org/ml/gdb-patches/2016-10/msg00381.html> real
> soon.
>
> [1] - most of the discussion happened in two threads here:
>
>  - https://sourceware.org/ml/gdb-patches/2016-10/msg00223.html
>  - https://sourceware.org/ml/gdb-patches/2016-10/msg00341.html
>
> Thanks,
> Pedro Alves
>

I'm ok with the transition to C++11 as long as we have a stable policy 
and decision to pursue it. We should avoid what just happened, that is, 
jump around whenever something that could be implemented better with a 
newer standard shows up.

It would be great if people manifesting their opinions offlist would do 
so through the list. After all, this is an upstream project and opinions 
from everyone are appreciated. Otherwise it feels like you are making 
this decision based on your own opinion of the matter. We never saw any 
of the several people that got in touch with you directly. :-)

As long as we have a sane codebase that makes contributions easier for 
everyone (instead of getting in the way with cryptic smarts and trickery 
simply to reduce code size), it should be good. Compilers are doing a 
better job these days anyway, and making code as compact as possible, 
though pleasing in some nerdy way, may not yield real benefit in the 
end. It may actually be harder to follow.

We don't want to lose the small number of contributors we have (which is 
a matter worth discussing in the future too).

Re: C++11 (abridged version)

[Tom Tromey]

>>>>> "Luis" == Luis Machado <lgustavo@codesourcery.com> writes:

Luis> It would be great if people manifesting their opinions offlist would
Luis> do so through the list. After all, this is an upstream project and
Luis> opinions from everyone are appreciated. Otherwise it feels like you
Luis> are making this decision based on your own opinion of the matter. We
Luis> never saw any of the several people that got in touch with you
Luis> directly. :-)

I try to limit my exposure to the list.

C++11 is a major improvement.  There are already existing patches that
it simplifies.  So I am in favor it; however I think a valid reason to
defer the transition would be if there is an active user base for whom
it would be unduly difficult to upgrade.  There are some weasel words in
there because I think some judgment must be involved.

Luis> As long as we have a sane codebase that makes contributions easier for
Luis> everyone (instead of getting in the way with cryptic smarts and
Luis> trickery simply to reduce code size), it should be good. Compilers are
Luis> doing a better job these days anyway, and making code as compact as
Luis> possible, though pleasing in some nerdy way, may not yield real
Luis> benefit in the end. It may actually be harder to follow.

I think the cases in question aren't of the form "shorter code is more
pleasing" but of the form "move the maintenance burden to the C++
library".  The former is aesthetic, but the latter means less work
locally.

Tom

Re: C++11 (abridged version)

[Eli Zaretskii]

> From: Pedro Alves <palves@redhat.com>
> Date: Thu, 20 Oct 2016 18:07:58 +0100
> 
> On #4 (policy for newer standard versions), as I've been saying many
> times in the past week, I think that what matters is whether there's
> reasonably widespread compiler availability, meaning the latest stable
> releases of distributions include a compiler for the standard, or it's
> easy to get one by installing some optional package.  If reasonably
> available, then we should switch, and take advantage of the great work
> our compiler and standards friends have been doing.

IMO, this is too vague for a policy.  I proposed a much more
quantitative criterion, one that doesn't run the risk of triggering
long disputes with no clear-cut ways of making a decision.  I'm okay
with other criteria, as long as they are clear, easily applied, and
don't require subjective interpretation.

My opinion on other items was already voiced here.

Re: C++11 (abridged version)

[Pedro Alves]

On 10/20/2016 08:05 PM, Eli Zaretskii wrote:
>> From: Pedro Alves <palves@redhat.com>
>> Date: Thu, 20 Oct 2016 18:07:58 +0100
>>
>> On #4 (policy for newer standard versions), as I've been saying many
>> times in the past week, I think that what matters is whether there's
>> reasonably widespread compiler availability, meaning the latest stable
>> releases of distributions include a compiler for the standard, or it's
>> easy to get one by installing some optional package.  If reasonably
>> available, then we should switch, and take advantage of the great work
>> our compiler and standards friends have been doing.
> 
> IMO, this is too vague for a policy.  I proposed a much more
> quantitative criterion, one that doesn't run the risk of triggering
> long disputes with no clear-cut ways of making a decision.  I'm okay
> with other criteria, as long as they are clear, easily applied, and
> don't require subjective interpretation.

Agreed.  That's why I concluded with:

~~~~
Going forward past C++11, since "reasonable availability" is not
quantifiable, Eli suggested the policy of

  "(...) waiting until the oldest compiler which supports that newer
  standard is at least 3 years old (like GCC 4.8.1 is today)."

And I agree with that.  (I'd prefix it with "at least".)
~~~~

I hope to have not misquoted you.  If I have, I apologize.

Thanks,
Pedro Alves

Re: C++11 (abridged version)

[Pedro Alves]

On 10/20/2016 08:09 PM, Pedro Alves wrote:
> On 10/20/2016 08:05 PM, Eli Zaretskii wrote:
>>> From: Pedro Alves <palves@redhat.com>
>>> Date: Thu, 20 Oct 2016 18:07:58 +0100
>>>
>>> On #4 (policy for newer standard versions), as I've been saying many
>>> times in the past week, I think that what matters is whether there's
>>> reasonably widespread compiler availability, meaning the latest stable
>>> releases of distributions include a compiler for the standard, or it's
>>> easy to get one by installing some optional package.  If reasonably
>>> available, then we should switch, and take advantage of the great work
>>> our compiler and standards friends have been doing.
>>
>> IMO, this is too vague for a policy.  I proposed a much more
>> quantitative criterion, one that doesn't run the risk of triggering
>> long disputes with no clear-cut ways of making a decision.  I'm okay
>> with other criteria, as long as they are clear, easily applied, and
>> don't require subjective interpretation.
> 
> Agreed.  That's why I concluded with:
> 
> ~~~~
> Going forward past C++11, since "reasonable availability" is not
> quantifiable, Eli suggested the policy of
> 
>   "(...) waiting until the oldest compiler which supports that newer
>   standard is at least 3 years old (like GCC 4.8.1 is today)."
> 
> And I agree with that.  (I'd prefix it with "at least".)
> ~~~~
> 
> I hope to have not misquoted you.  If I have, I apologize.

Here's a straw man proposal for the policy text:

When is GDB going to start requiring C++NN ?

Our general policy is to wait until the oldest compiler which
supports C++NN is at least 3 years old.

Rationale: We want to ensure reasonably widespread compiler availability,
to lower barrier of entry to GDB contributions, and to make it easy for users
to easily build new GDB on currently supported stable distributions themselves.
3 years should be sufficient for latest stable releases of distributions to
include a compiler for the standard, and/or for new compilers to appear as
easily installable optional packages.  Requiring everyone to build a compiler
first before building GDB, which would happen if we required a too-new compiler,
would cause too much inconvenience.

WDYT?

Thanks,
Pedro Alves

Re: C++11 (abridged version)

[Eli Zaretskii]

> Cc: gdb-patches@sourceware.org
> From: Pedro Alves <palves@redhat.com>
> Date: Thu, 20 Oct 2016 20:41:39 +0100
> 
> Here's a straw man proposal for the policy text:
> 
> When is GDB going to start requiring C++NN ?
> 
> Our general policy is to wait until the oldest compiler which
> supports C++NN is at least 3 years old.
> 
> Rationale: We want to ensure reasonably widespread compiler availability,
> to lower barrier of entry to GDB contributions, and to make it easy for users
> to easily build new GDB on currently supported stable distributions themselves.
> 3 years should be sufficient for latest stable releases of distributions to
> include a compiler for the standard, and/or for new compilers to appear as
> easily installable optional packages.  Requiring everyone to build a compiler
> first before building GDB, which would happen if we required a too-new compiler,
> would cause too much inconvenience.
> 
> WDYT?

Fine with me, thanks.

Re: C++11 (abridged version)

[Pedro Alves]

On 10/20/2016 08:56 PM, Eli Zaretskii wrote:
>> Cc: gdb-patches@sourceware.org
>> From: Pedro Alves <palves@redhat.com>
>> Date: Thu, 20 Oct 2016 20:41:39 +0100
>>
>> Here's a straw man proposal for the policy text:
>>
>> When is GDB going to start requiring C++NN ?
>>
>> Our general policy is to wait until the oldest compiler which
>> supports C++NN is at least 3 years old.
>>
>> Rationale: We want to ensure reasonably widespread compiler availability,
>> to lower barrier of entry to GDB contributions, and to make it easy for users
>> to easily build new GDB on currently supported stable distributions themselves.
>> 3 years should be sufficient for latest stable releases of distributions to
>> include a compiler for the standard, and/or for new compilers to appear as
>> easily installable optional packages.  Requiring everyone to build a compiler
>> first before building GDB, which would happen if we required a too-new compiler,
>> would cause too much inconvenience.
>>
>> WDYT?
> 
> Fine with me, thanks.
> 

FYI, I've now added this to the coding standards:

 https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards?action=diff&rev1=19&rev2=20

... along with mentioning the C++11 requirement.

Thanks,
Pedro Alves

Re: C++11 (abridged version)

[Eli Zaretskii]

> Cc: gdb-patches@sourceware.org
> From: Pedro Alves <palves@redhat.com>
> Date: Thu, 20 Oct 2016 20:09:18 +0100
> 
> ~~~~
> Going forward past C++11, since "reasonable availability" is not
> quantifiable, Eli suggested the policy of
> 
>   "(...) waiting until the oldest compiler which supports that newer
>   standard is at least 3 years old (like GCC 4.8.1 is today)."
> 
> And I agree with that.  (I'd prefix it with "at least".)
> ~~~~
> 
> I hope to have not misquoted you.  If I have, I apologize.

No need to apologize, the citation is accurate.

Thanks.

Re: C++11 (abridged version)

[Yao Qi]

On Thu, Oct 20, 2016 at 1:07 PM, Pedro Alves <palves@redhat.com> wrote:
> At this point, I find myself in an odd position --- several people
> have been telling me offlist how they wanted C++11 like yesterday already.
> There was support in last week's discussions as well.  OTOH, I'm not
> sure whether I can assume that silence on the list means "go ahead".
> So I think I'll need to call a bold move and say that if there are no
> actual identified blockers, or if people reply to this email with
> approval, I'm going to proceed with the straw man 'path toward
> C++11' proposal at
> <https://sourceware.org/ml/gdb-patches/2016-10/msg00381.html> real
> soon.
>
> [1] - most of the discussion happened in two threads here:
>
>  - https://sourceware.org/ml/gdb-patches/2016-10/msg00223.html
>  - https://sourceware.org/ml/gdb-patches/2016-10/msg00341.html

Hi Pedro,
I kept silence on the discussion in the past several weeks, because
I don't know much on C++.  I can't think of any reason we should
block C++ 11 transition.  I've got "C++ Primer, fifth edition" on my
desk.  It covers C++ 11 :)

It is a right thing to move to C++ 11.  However, we need to think
about the priority of each work.  We still have bugs to fix, new features
to add, patches to review.  They are very important in the short term,
next release, for example.  We can't afford several months doing code
conversion without any real development and bug fixes.  Code
conversion should be a background task, running along with development
and bug fixes for some years.

-- 
Yao (齐尧)

Re: C++11 (abridged version)

[Pedro Alves]

On 10/20/2016 08:37 PM, Yao Qi wrote:
> Hi Pedro,
> I kept silence on the discussion in the past several weeks, because
> I don't know much on C++.  I can't think of any reason we should
> block C++ 11 transition.  I've got "C++ Primer, fifth edition" on my
> desk.  It covers C++ 11 :)
> 
> It is a right thing to move to C++ 11.  However, we need to think
> about the priority of each work.  We still have bugs to fix, new features
> to add, patches to review.  They are very important in the short term,
> next release, for example.  We can't afford several months doing code
> conversion without any real development and bug fixes.  Code
> conversion should be a background task, running along with development
> and bug fixes for some years.

Definitely agreed.  Myself I've been spending more time on it
than I can really afford.  My idea in the past weeks was to
plant the seed for others to come in and help (e.g., the
std::string patches and the gdb::unique_ptr patches).  I had
no idea getting that done would take this long...

Thanks,
Pedro Alves

Re: C++11 (abridged version)

[Keith Seitz]

Hi, Pedro,

I'm normally a "go with the flow" kind of person, and I've pretty much
had my head buried in the compile "sand," but I felt this topic
important enough to say something -- even if it has already been said.

TL;DR: I'm *all* for moving directly to C++11. I'm already using quite a
bit of it on C++ Compile.

On 10/20/2016 10:07 AM, Pedro Alves wrote:

> A large discussion around that patch followed [1], circling around a
> few related points:
> 
> #1 - whether we should be reimplementing C++11 features.
> 

Developers will undoubtedly find future standard library (or boost)
concepts, algorithms, etc useful now. Sometimes *very* useful.
std::unique_ptr (and I'd argue shared_ptr) is such a case we are seeing
today.

A requirement to maintain some backward-compatibility
(compiler-longevity?) necessarily leads to implementing some of the
newer, highly-desirable/beneficial library features ourselves. I don't
think this is an uncommon practice.

For me this C++11 "now" decision arises from the realization that C++11
is so much more useful that we might as well simply jump straight to
using it. It contains a handful of concepts that would be non-trivial or
perhaps even impossible to implement outside direct compiler support,
e.g., "auto", lambda functions, ...

While I'm no C++ guru, I don't think I would be alone in saying that
C++11 is the language specification C++ should have had years ago.

> #2 - whether we should be taking advantage of C++11 features when
>      available, provided we have C++03 fully functional fallbacks in
>      place.  (and then generically, $version+1 features provided we
>      have $version fallbacks.)

I'm generally fine with this. Again it seems a "necessary evil."

However, there is one concern I have, and the recent unique_ptr patch
exemplifies this.  We now have a "unique_ptr." In fact, when using a
real C++11 compiler, gdb_unique_ptr.h will actually just alias a real
C++11 std::unique_ptr to gdb::unique_ptr.

Alas,

> - Putting gdb::unique_ptr in standard containers is not supported,
>   since C++03 containers are not move-aware (and our emulation
>   relies on copy actually moving).

The comment above shows that while the two are similarly named,
gdb::unique_ptr isn't yet really a real unique_ptr. However, for
developers like me who do use a C++11-compliant compiler, that's one
hidden gotcha waiting to be discovered.

Fortunately, I read the sources and discovered this before I used
unique_ptr in containers on the c++compile branch. I'm (mildly)
concerned that this could too easily lead to yet-another "our own
dialect" of C++(11) scenario(s).

Of course, it is *far* too early to make any concrete assertions about
this. The code has only been in the repository one week.

> #3 - whether we should instead switch to require a C++11 compiler
> 

We gotta start somewhere, and IMO, C++11 is *by far* the best "safe"
place to do so.

> #4 - if so, then what is the policy to accept the next standard
>      versions going forward.

I don't know how comfortable I am with such black-and-white rules, but I
think/hope that maintainers remain *flexible* about decisions like this.
Do what is "right" when it is "right." [That's not a "rule," per se, but
what I'd like the "spirit" of the rule to be.]

I think your offering on this policy indicates that you and I are in
agreement.

I'm already using C++11 features, and I am absolutely in favor of moving
directly to C++11.

TL;SW*

Keith

* Too Long; Stopped Writing :-)

Re: C++11 (abridged version)

[Pedro Alves]

On 10/25/2016 09:29 PM, Keith Seitz wrote:
> Hi, Pedro,

Hi Keith!  Thanks for dialing in.

> 
> I'm normally a "go with the flow" kind of person, and I've pretty much
> had my head buried in the compile "sand," but I felt this topic
> important enough to say something -- even if it has already been said.
> 
> TL;DR: I'm *all* for moving directly to C++11. I'm already using quite a
> bit of it on C++ Compile.

How forward-thinking.  :-)

> However, there is one concern I have, and the recent unique_ptr patch
> exemplifies this.  We now have a "unique_ptr." In fact, when using a
> real C++11 compiler, gdb_unique_ptr.h will actually just alias a real
> C++11 std::unique_ptr to gdb::unique_ptr.
> 
> Alas,
> 
>> - Putting gdb::unique_ptr in standard containers is not supported,
>>   since C++03 containers are not move-aware (and our emulation
>>   relies on copy actually moving).
> 
> The comment above shows that while the two are similarly named,
> gdb::unique_ptr isn't yet really a real unique_ptr. 

Right, it's a subset of the API.  Containers are probably where
we actually miss something.  Stateful deleters, etc., not so much.

> However, for
> developers like me who do use a C++11-compliant compiler, that's one
> hidden gotcha waiting to be discovered.

The problem is really on the C++03 containers side more than anything.
There's no way to make C++03 standard containers work correctly with
non-copyable and movable types.  That's why you can't put old
std::auto_ptr in containers either.

boost's unique_ptr emulation supports putting their unique_ptr
in containers, but only because they re-implement the
containers too...  I.e., not in standard container either.

> 
> Fortunately, I read the sources and discovered this before I used
> unique_ptr in containers on the c++compile branch. I'm (mildly)
> concerned that this could too easily lead to yet-another "our own
> dialect" of C++(11) scenario(s).

Yeah...  You just can't do

 std::vector<gdb::unique_ptr <foo>> m_vec;

instead you have to do:

 /* Vector owns objects.  */
 std::vector<foo *> m_vec;

and then destroy the vector's elements yourself, usually
in the destructor of the class m_vec belongs to.

I have examples here (and in other patches of that series):

 https://sourceware.org/ml/gdb-patches/2016-10/msg00531.html

-  /* size of array pointed to by expr_list elt.  */
-  long aexpr_listsize;
-  long next_aexpr_elt;
-  struct agent_expr **aexpr_list;
+  /* Vector owns pointers.  */
+  std::vector<agent_expr *> m_aexprs;
 
...

collection_list::~collection_list ()
{
  for (int ndx = 0; ndx < m_aexprs.size (); ndx++)
    free_agent_expr (m_aexprs[ndx]);
}


So basically you still use gdb::unique_ptr throughout to manage
object's lifetime, and then when "moving" the object to a
container, you release the object out of the unique_ptr
and put the raw pointer in the container.  No way out of
that with C++03, with any kind of owning smart pointer,
not just gdb::unique_ptr.

At:
 https://sourceware.org/ml/gdb-patches/2016-10/msg00537.html

see an example of this moving in action:

  void
 -collection_list::add_aexpr (struct agent_expr *aexpr)
 +collection_list::add_aexpr (agent_expr_up aexpr)
  {
 -  m_aexprs.push_back (aexpr);
 +  m_aexprs.push_back (aexpr.release ());
  }

Actually strictly speaking that can leak if push_back throws
(due to out of memory)  A more correct way to write that would be:

  m_aexprs.push_back (aexpr.get ());
  aexpr.release ()

I didn't bother with that, but maybe I should have.  It
uglifies the code a bit...  I guess we could add a helper
template class for that:

  m_aexprs.push_back (move_to_container (aexpr));

move_to_container would be a function that returns
an instance of a class convertible to the raw pointer type,
in order to pass the raw pointers to push_back,
and, that class would release the smart pointer in its
destructor. The temporary's destructor only runs after
push_back returns.

If we go C++11, the above example can be:

 std::vector<std::unique_ptr <agent_expr>> m_aexprs;

the pushing on the vector is then simply:

  m_aexprs.push_back (std::move (aexpr));

and the collection_list destructor can be completely eliminated..


> 
> Of course, it is *far* too early to make any concrete assertions about
> this. The code has only been in the repository one week.

Yeah.  I think it's not that bad of a trade off.  The container
issue is easy to work around, it's still standard C++, and and, a
unique_ptr put directly in a container would have to pass code review,
while it's very easy to spot.  If it does pass review, it's still
fixable without any algorithmic redesign.  You just have to do
more things manually.

> 
>> #3 - whether we should instead switch to require a C++11 compiler
>>
> 
> We gotta start somewhere, and IMO, C++11 is *by far* the best "safe"
> place to do so.
> 
>> #4 - if so, then what is the policy to accept the next standard
>>      versions going forward.
> 
> I don't know how comfortable I am with such black-and-white rules, but I
> think/hope that maintainers remain *flexible* about decisions like this.
> Do what is "right" when it is "right." [That's not a "rule," per se, but
> what I'd like the "spirit" of the rule to be.]
> 
> I think your offering on this policy indicates that you and I are in
> agreement.

*nod*

> 
> I'm already using C++11 features, and I am absolutely in favor of moving
> directly to C++11.
> 
> TL;SW*
> 
> Keith
> 
> * Too Long; Stopped Writing :-)
> 

Thanks,
Pedro Alves

Re: C++11 (abridged version)

[Kevin Buettner]

On Thu, 20 Oct 2016 18:07:58 +0100
Pedro Alves <palves@redhat.com> wrote:

> My opinion on #3 (should we require C++11 now), is yes.  C++11 is a
> great step up from C++03, and being able to use it fully would result
> in a more efficiency gdb, and would also allow simplifying things that
> require ugly workarounds in C++03.  I.e., if you hate C++ and you think
> it's messy, it may actually be that what you hate is C++03, and that you'd
> actually like C++11 if you give it a chance.  E.g., rvalue references, efficient
> move-aware containers (also allowing us to make containers "own" the containing
> objects, resulting in even simpler code), template aliases, variadic templates,
> etc. etc.  C++11 would avoid having to consider reimplementing basic utilities
> like e.g., a type-safe hash table.  C++11 is also a _simpler_ language in a way,
> as some ugly warts have been ironed out in the language (e.g., std::string
> and contiguous buffer guarantees).

While I claim no deep understanding of C++ (any version), I find this
point compelling.  Therefore, I'm in favor of requiring C++11 for
building GDB.

Kevin

Re: C++11 (abridged version)

[Pedro Alves]

On 10/20/2016 06:07 PM, Pedro Alves wrote:

> My opinion on #3 (should we require C++11 now), is yes.  C++11 is a
> great step up from C++03, and being able to use it fully would result
> in a more efficiency gdb, and would also allow simplifying things that
> require ugly workarounds in C++03.  I.e., if you hate C++ and you think
> it's messy, it may actually be that what you hate is C++03, and that you'd
> actually like C++11 if you give it a chance.  E.g., rvalue references, efficient
> move-aware containers (also allowing us to make containers "own" the containing
> objects, resulting in even simpler code), template aliases, variadic templates,
> etc. etc.  C++11 would avoid having to consider reimplementing basic utilities
> like e.g., a type-safe hash table.  C++11 is also a _simpler_ language in a way,
> as some ugly warts have been ironed out in the language (e.g., std::string
> and contiguous buffer guarantees).

Seems like pretty much everyone is in agreement with this, so
I've sent a new patch set for this now:
  https://sourceware.org/ml/gdb-patches/2016-10/msg00773.html

I'd appreciate a review.

Thanks,
Pedro Alves