[lldb-dev] Help with C++ API
jingham at apple.com
jingham at apple.com
Wed Aug 28 17:08:19 PDT 2013
The nice thing about doing it the way the SBValues do it now is that you can implement the policy for how variables are going to be displayed at the time you create the values, and then you can just hand the values out to whatever viewers you have, and if they use the simple GetChildAtIndex API's they will obey that policy automatically. I don't think in normal debugger usage you would want to display BOTH the synthetic view of a type AND the the raw view, so the current implementation nicely encapsulates the most common usages.
You can always dial up the specific view options you want later on (for instance by calling the GetChildAtIndex that takes use_dynamic and can_create_synthetic.) You can also fetch the synthetic or dynamic SBValue by hand if you want to ensure you are working with the synthetic children. So you can choose to present data any way you want. We just make it easy to move the choice to value creation time.
Note that the "synthetic" children have other uses besides just emulating STL containers. For instance if you have a complex data structure, but used for purpose A only the first 5 fields are used, and for purpose B fields 1, 5, 7 and 9 are used. So you would make two simple synthetic child providers, one of which returns the first 5 fields, etc, and then you could turn on and off these synthetic child providers according to the problem you are currently debugging. In lldb, the Command access to this feature is by using a type "filter" but under the covers it is just another synthetic child provider.
So it would be narrowing to view the "synthetic children" as only a framework for viewing container types.
On Aug 28, 2013, at 4:23 PM, Jakob Leben <jakob.leben at gmail.com> wrote:
> On Wed, Aug 28, 2013 at 3:30 PM, Jakob Leben <jakob.leben at gmail.com> wrote:
> 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.
> After all, it would actually make a lot of sense to me to have a separate API (C++ class) for "synthetic" (better named "formatted") observation of complex data structures, as opposed to having a single boolean flag in SBValue control such a drastic distinction between SBValue API semantics with regard to the concept of "children".
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
More information about the lldb-dev