[lldb-dev] Help with C++ API

[Enrico Granata]

On Aug 28, 2013, at 2:05 PM, Jakob Leben <jakob.leben at gmail.com> wrote:

> On Wed, Aug 28, 2013 at 11:25 AM, Enrico Granata <egranata at apple.com> wrote:
>> That makes sense. An std::string only has one child, which is a struct that
>> then contains the pointer
>> std::string has no synthetic children, also.
>> It only has a summary.
> 
> Well, we have established that "elements" of a std::list are only
> called so in a "synthetic" sense. I think characters are elements of a
> std::string in exactly the same sense, so I think the same API should
> support accessing both.
> 
> Moreover, the "summary" has the notion of pretty-printing, and does
> not seem logically suitable for actual-data access.
> 
> What do you think of this?

If you feel the need for a synthetic children provider for std::string that vends the actual characters as items, then by all means feel free to make one.

I think such a visualization would be highly inconvenient for most users most of the time, much as you do not want to see a char* so much as an array of chars but rather as a logical “string”, the same is true of std::string
Also, if you know the layout of the string class, you can directly access the data buffer and read the individual bytes out of memory, which is also a discouraging argument from going down the synthetic children route: the added value compared to the actual type layout is quite low.
This is why LLDB vends a summary instead of synthetic children.

Nothing says that you cannot vend both of course (a vector vends a summary, the count, and then the individual items as children), so you could keep the builtin summary and then plug your own synthetic children provider for the purpose of fetching the individual bytes if you need this level of access.
If you need support to figure out the moving parts in this process, feel free to ping back :)

Enrico Granata
📩 egranata@.com
☎️ 27683


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20130828/eba99197/attachment.html>