[lldb-dev] Help with C++ API

[Jakob Leben]

On Wed, Aug 28, 2013 at 2:48 PM, Enrico Granata <egranata at apple.com> wrote:

> We cannot (or do not want) to vend any possible data view through the
> builtin formatters, but we vend a formatters model through which you can
> vend whatever formatting suits your needs
> Yes, unfortunately that means that you need to know a little more about
> your types, but somebody needs to “bake the knowledge” in LLDB [1], whether
> it’s me writing a builtin formatter, or you writing your own
>
> What you are trying to access is really not “raw data”.
>
[...]
>

 You are right, I should be corrected that what I want to access is not
really raw data, but data formatted in some sense.

However, my point was that we could distinguish (at least) two kinds of
formatters:
a) pretty-printing formatters: they format data for display as strings for
humans to read - the user is the human eye.
b) programming-access formatters: they format data for convenient use in
code (e.g. C++) - the user is the code.

You could see a C++ programming interface as a type b) formatter: the C++
STL specification practically defines how data structures should be viewed,
interacted with, by user-code, regardless of how they are implemented (in
memory and implementation-code). So for example the std::string API is
already a formatter in itself, but the issue in debugging another process
is of course that we can't simply use the address of a std::string in
target program's memory as a std::string pointer in the host program and
use it just as any other std::string.

Now, obviously LLDB offers a generic way to implement formatters of both
types. Naturally, it offers access to raw data, so one can do anything they
please with it. But then again, you can access raw data even without the
LLDB C++ API! So from the point of view of a C++ API user, what's valuable
in LLDB library is not the fact that they can build formatters of their own
from raw data, but rather the already built-in formatters.

Secondly, from the point of view of a LLDB C++ API user, if any built-in
formatters are useful, those would be formatters of type b). Arguments:
1. Primarily, the data accessed through a C++ API should be formatted for
use by client C++ code, and not for use by the human eye.
2. Formatting of type a) can be built on-top-of formatting of type b), but
not the other way around.
3. Consequently, formatting of type a) is most probably implicit within the
implementation of formatting of type b), type a) will arguable often
correspond to a layer within the implementation of type b). So why not
expose this layer through the API?

But since formatters are specific to any C++ library and machine
architecture (and are in this sense a Simple-Matter-of-Programming [1]) I
can accept the answer that this is just not implemented, and I can go and
do it myself if I want. But instead, we are discussing here the semantics
of the generic LLDB C++ API, what interpretation of it makes sense and what
doesn't, and what functionality should be offered behind the API.

So in this regard I argue that it makes sense for characters within a
std::string to be offered as "children" in the context of the SBValue API.
To repeat, I think this sense is exactly the same as the sense of
"children" with regard to std::vector and std::list. This argument can
further be supported by the fact that STL specification offers same
mechanisms to iterate through elements of a std::string, std::vector or
std::list. It can further be argued that a SBValue should offer as children
*anything* that is offered by *any* STL container as its elements, and
furthermore that this becomes a de-facto simple and elegant definition of
SBValue semantics with regard to children and with regard to STL containers.

[1] http://en.wikipedia.org/wiki/Simple_matter_of_programming
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20130828/912fcb59/attachment.html>