Re: [patch] Support C++11 rvalue (move constructor)

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Mon, 14 Oct 2013 20:18:51 +0200, Tom Tromey wrote:
> >> Is that also true for inferior calls?
> >> I didn't look.
> 
> Jan> GDB cannot call constructors so this is irrelevant now.
> 
> I'm not sure constructors matter.  rvalue references affect overloading,
> e.g.:
> 
>     #include <stdio.h>
> 
>     int ov(int &x) { return 0; }
>     int ov(int &&x) { return 1; }
> 
>     int main() {
>       int z = 23;
>       printf ("%d %d\n", ov(z), ov(23));
>     }

OK, true.  I see && already works fine due to the C++11 libiberty/ demangler.
(gdb) complete p 'ov
p 'ov(int&&)
p 'ov(int&)

Just inferior calls pick randomly the function depending on their order in
source (in DWARF):
(gdb) p ov(z)
$1 = 0
vs.
(gdb) p ov(z)
$1 = 1

This means we should really have two distinct TYPE_CODEs and then properly
select lvalue vs. rvalue function depending on the type of argument used passed
for the inferior call.  Possibly failing to find the function if function only
accepts rvalue but user passes in real variable (lvalue).

The patch is definitely incorrect as is but I would say it is better than
nothing.  The proper rvalue implementation is some work and I would say I have
other work to do.


> Tom> Maybe the size increase isn't that important.
> 
> Jan> I always thought the opposite is true.
> Jan> Due to CU expansion with <tab> after some completions one easily gets to
> Jan> 1GB GDB and more (but IMO this is a bug <tab> should not expand CUs).
> 
> I think what's missing is an idea of the amount that struct main_type
> contributes.
> 
> My recollection is that I concluded that shrinking types wasn't
> worthwhile.  However, it's worthwhile to redo the experiment, at least
> if you plan to completely fix this problem.

I find clear the <tab> CU expansion should be fixed.  Then maybe GDB stops
growing.  Or maybe not (and then one has to look more at main_type...).


Jan