Re: Variable objects and STL containers

[Nick Roberts <nickrob@snap.net.nz>]

 > > Will the Python integration be self contained or does it require separate
 > > libraries?  
 > 
 > To use Python you'd need a Python interpreter library.
 > 
 > > Will it restrict the number of platforms that GDB builds on? 
 > 
 > If you don't have Python, Python support won't be compiled.

So if you don't have Python, your patch for variable objects for STL containers
will not work.

 > > In any case, there seem to be two projects here: Python integration and
 > > the display of STL containers using variable objects.  It's not clear to
 > > me that the former is necessary for the latter.
 > 
 > Well, I have patches in the works for both.

Can they be presented separately?

 > > Below is just a quick sketch of the thoughts I have, which may or may not
 > > be sensible.
 > > 
 > > In the case of vectors, var->num_children would be computed from n =
 > > v._M_impl._M_finish - v._M_impl._M_start and the children would be created
 > > from *(v._M_impl._M_start+1), *(v._M_impl._M_start+2),
 > > ...*(v._M_impl._M_start+n).
 > 
 > I think it should be: *(v._M_impl._M_start+0),...,*(v._M_impl._M_start+n-1).

Yes.

 > > I guess a special variable object would need to be created for n and when
 > > it was reported as changed bt -var-update, new/old variable objects could
 > > accordingly be created/deleted.
 > 
 > I don't see why we need a separate variable object. If the number of
 > children of a variable object changes, then -var-update can include that
 > variable object in the result (and tell the new number of children). 

I just think it might mean that the output of -var-update need not change.
If n changes the frontend can create/delete the extra/old variable objects.

 > Now the question is whether the children that are no longer present should
 > be deleted, and whether new children should be auto-created.
 > 
 > It is probably better to auto-delete varobjs corresponding to the children
 > that are gone. Then, -var-update output will list those children, with
 > 'in_scope' attribute mentioning varobj is gone. Frontend is most likely to
 > want those varobjs to be gone, and doing this automatically saves frontend
 > complexity.

I think it may involve a bigger change to the MI output.

 > Note that even if frontend wants to hold to the value of now-deleted child,
 > for some reason, it must do it explicitly. Suppose that we don't auto-delete
 > children, and the number of children first decreases by one and then
 > increases by one.  The varobj that corresponds to the last original child
 > now is not accessible in any way. It's not accessible via children list of
 > it's parent. It's not accessible by the name -- as the name got reused when
 > new child is added. So, we cannot even get the value of that varobj.

I don't think we should worry about keeping the value of STL members that
have been deleted - at least for now.

 > I think that likewise, -var-update should create varobjs for new children,
 > and return them -- we probably need a new attribute to indicate that a
 > varobj was just created. This might sound like breaking frontends not
 > prepared to see new varobjs in -var-update output. However, this dynamic
 > child behaviour will happen only as result of explicit request from
 > frontend.

AFAIK, if three new members are created and two deleted, all the executable
needs to know is that there is one new member.  That's why I think it may be
simple to just have a special variable object that tells the front end when the
number of members changes.

 > It's natural to give frontend a choice between 'raw' representation and
 > 'pretty' representation, and for compatibility, it's best to default to
 > 'raw'. And if frontend asks gdb to use pretty representation for a varobj,
 > or all varobj of given type, we can expect the frontend to property handle
 > auto-created varobjs.

An option for this sounds like a good idea.

 > Does this make sense?

Overall, it does.  I think it would be a good idea to allow room for possible
changes in implementation detail.

-- 
Nick                                           http://www.inet.net.nz/~nickrob