<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 28, 2013 at 2:48 PM, Enrico Granata <span dir="ltr"><<a href="mailto:egranata@apple.com" target="_blank">egranata@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>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</div>
<div>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 </div><div>
<br></div><div>What you are trying to access is really not “raw data”. </div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>[...]</div></blockquote><div><br></div><div> You are right, I should be corrected that what I want to access is not really raw data, but data formatted in some sense.</div><div><br></div><div>However, my point was that we could distinguish (at least) two kinds of formatters:</div>
<div>a) pretty-printing formatters: they format data for display as strings for humans to read - the user is the human eye.</div><div>b) programming-access formatters: they format data for convenient use in code (e.g. C++) - the user is the code.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.<br>
</div><div><br></div><div>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:</div><div>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.</div>
<div>2. Formatting of type a) can be built on-top-of formatting of type b), but not the other way around.</div><div>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?</div>
<div><br></div></div>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. </div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">[1] <a href="http://en.wikipedia.org/wiki/Simple_matter_of_programming">http://en.wikipedia.org/wiki/Simple_matter_of_programming</a><br><br></div></div>