Re: [python] StdStringPrinter misleading?

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Thiago" == Thiago Jung Bauermann <bauerman@br.ibm.com> writes:

Tom> Yeah, it may not.  That is a general problem with C++ printers,
Tom> because the typical C++ object has a bunch of pointers to other
Tom> objects, which probably will not live in values.

Thiago> So one can't assign a std::string value to a convenience
Thiago> variable? or it means that parts of it will be in the inferior
Thiago> anyway?

Yeah, if you assign one to a convenience variable, parts of it will
still live in the inferior.

We could probably fix this.  One way would be to reuse the existing
pretty-printers -- instead of printing anything, use them to determine
what bits needs to be fetched into values on the gdb side.  Then, we
at least know we will be able to print them in the future.  (This
change would be non-trivial, though, since it would require some kind
of hash map of addresses to struct value.)

Thiago> Right. I agree with you. From reading the patch I thought that
Thiago> self.val['_M_dataplus']['_M_p'] would be all that one needs to read to
Thiago> get the string. Brainfart, I guess.

Hah, if there was one it was mine, when I wrote this code the first
time :)

Thiago> So perhaps having an optional length argument to the string
Thiago> method could indeed make life easier in cases like this.

I was thinking about this problem a bit more this afternoon.  It
occurred to me that counted strings are reasonably common in user
code, so we'd want some way to express that, even if we put
language-specific information (like std::string) into the gdb core.
Whether this way is value.string or gdb.read_memory, I don't know.
I lean toward string, but if you have a preference...

Tom