[lldb-dev] Help with C++ API

[Joseph Galbraith]

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.)

Thanks,

Joseph

PS. I may not qualify as most people either :-)