On Wed, Aug 28, 2013 at 2:15 PM, Enrico Granata <[email protected]> wrote: > 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.
I see you point. I am approaching the issue from another perspective though: I am building an application with the concept of "programming-model-aware debugging", specifically data-flow programming model. I found the LLDB C++ API valuable, because it allows me to easily build an application that attaches to another process which performs processing of a data-flow graph (think multimedia processing) and displays the processing behavior in a graphical way. So I consider the LLDB C++ API as a convenient utility and abstraction on top of operating-system-provided debugging facilities, but for other purpose than implementing a classical command-line debugger. Instead, it is used as a utility to examine another program's state and data in a convenient way. Therefore, in my use case I need to access the *actual* data to display it to the end-user in any arbitrary way that LLDB API should never need to assume in itself. Providing a summary/value of a data structure's contents as a string (returned by GetSummary() or GetValue()) is an example of such an assumption. _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
