[lldb-dev] Help with C++ API
galb at vandyke.com
Thu Aug 29 12:26:08 PDT 2013
On 2013/08/29 12:07, Enrico Granata wrote:
> On Aug 28, 2013, at 7:15 PM, Jakob Leben <jakob.leben at gmail.com
> <mailto:jakob.leben at gmail.com>> wrote:
>> On Wed, Aug 28, 2013 at 5:08 PM, <jingham at apple.com
>> <mailto:jingham at apple.com>> 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.)
PS. I may not qualify as most people either :-)
More information about the lldb-dev