Re: [RFA 02/22] Use RAII to save and restore scalars

[Pedro Alves <palves@redhat.com>]

On 10/02/2016 06:11 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
> 
>>> However, once you need a copy constructor, it doesn't seem possible
>>> without a move constructor.  The issue is that a copy constructor take a
>>> const reference, so you can't modify the fields of the original.
> 
> Pedro> You can -- make the fields mutable.
> 
> Ok, yeah, I had thought of this, but it seemed pretty ugly to me.

It's hidden in the "library", so it'd be super fine with me.
I think of it as just part of the idiom.

> 
> Instead I removed all the 2 argument forms in favor of a second explicit
> assignment.  This solves the problem as well.

OK, I thought a little bit more about my worry with the implicit
copy constructor, and I think I was originally right -- it doesn't
make a difference; things still work if the compiler doesn't elide,
because the single-argument form doesn't change the global.  Guess
you could confirm things still build and run properly
with -fno-elide-constructors.

> I can go back and do the mutable thing if you really prefer it though.

I don't have a strong preference.  Maybe client code using the 1-argument form
ends up looking cleaner, in any case, not sure.

> 
> 
> Pedro> The gist is that I think that the features supported by compilers that
> Pedro> people are using in practice to build gdb with is what matters
> Pedro> in the end, not really C++03 vs C++11.
> 
> The issue I see is that it's just too easy otherwise for C++11isms to
> slip in, especially considering that everybody doing development is
> likely to be using a compiler with all the C++11 features.  Maybe
> buildbot can do C++03 builds to check.

I still disagree to an extent.  Even if we were claiming to
require "C++11", we probably wouldn't be able to use _all_ of C++11.
E.g. if we wanted to require full C++11 support, then we're need to
require gcc 4.8, which was released in 2013.  I'd be super fine with
requiring it personally, and I look forward to the day, tbc!
I think it's present in all current versions of major distros, I
believe,  I wouldn't be surprised to find opposition, though.

As compromise, I think we could be much better at documenting the older gcc version
that we actually support compiling with.  That oldest-supported version, I think
should be decided based on what's the oldest version people really care about,
and are willing to routinely test, vs how bad we'd want the C++11 features
not supported by that old compiler.  Last this was discussed, in context of
deciding whether to move forward with the C++ conversion, we settled on gcc 4.2
at least, since that's what some BSDs were still using.  But we have nothing in
place to enforce that, and I suspect that we still build correctly with
older gcc's even.  Or not, I don't know, since no one is testing it, for all I
know (i.e., no one is sending test reports to gdb-testers@).  I think all BSDs have
llvm/clang in their base systems now, so those are probably no longer really a concern.

Because, if we could require say, gcc 4.3 at least, then we
could make use of rvalue references.  If we required gcc 4.4, then we
could use "auto" and other goodies.  Etc.  IOW, if we took an incremental
approach, we'd be bound by the level of C++11 support in the oldest
compiler we supported.  

  https://gcc.gnu.org/projects/cxx-status.html#cxx11

And _that_ version is what I think should be tested by the buildbot,
irrespective of C++98/C++03/C++0x/C++11/... instead of being artificially
blocked by -std=c++03 or some such.

Thanks,
Pedro Alves