On 2013/08/29 12:07, Enrico Granata wrote:
On Aug 28, 2013, at 7:15 PM, Jakob Leben <[email protected]
<mailto:[email protected]>> wrote:
On Wed, Aug 28, 2013 at 5:08 PM, <[email protected]
<mailto:[email protected]>> wrote:
So it would be narrowing to view the "synthetic children" as only a
framework for viewing container types.
Perhaps what I've missed is that there can be several different
synthetic child providers for any parent data type. Even in that case,
it seems there is one such provider that's installed on an SBValue
provided via C++ API by default. So then my proposal applies to these
default providers.
There can only be one synthetic provider per type that is active.
If you end up installing multiple, through regexp or whatnot, the order
of categories determines which one wins.
Technically, a category can only ever contain one provider per type.
With regular expressions it is fairly easy to violate this requirement.
What happens then is undefined (i.e. it depends on the order in which
they were added or in which the iterators we use provide them to us for
inspection, …) long story short: don’t rely on any such tricks.
Besides, it's not that SBValue for std::string provides synthetic
children in a different way than I would like. The issue is that it
doesn't provide synthetic children at all! And so far I simply haven't
heard any good reason why it shouldn't by default provide characters
as children.
It is a largely uninteresting view for most people. The majority of
people using LLDB have never expressed the desire to twist their strings
open and see an array of characters. Actually, there has been an
opposite drive: even a char[] should be displayed as a string.
This is really the only reason why that was not implemented.
As a debugger user I definitely want things (even a char[]) displayed as
strings most of the time; however, I do occasionally wish to open the
string up and see the raw characters.
For example, yesterday I was troubleshooting an bug with a spurious
newline character... being able to see the raw character data in an
unambiguous way would have been useful in that case and other cases
involving characters that don't display in an "obvious" way (other
non-printing characters, combining characters, etc.)
On the other hand, if it's going to introduce a 10% performance penalty
in the display as string case, I'll do without.
So while it is rare enough that it hasn't driven me to try and fix it, I
would have occasional use for the feature.
(I did implement a summary provider for std::wstring before lldb
provided one out of the box because that pain was huge for me.)
Thanks,
Joseph
PS. I may not qualify as most people either :-)
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
