This is the mail archive of the
mailing list for the GDB project.
RE: [PATCH:MI] Return a subset of a variable object's children
Nick Roberts wrote:
> > > step size (stride) other than one.
> > I'm not sure what the stride would be used for. Maybe something like
> > printing all even indexes of an array for example? In any case, it is a
> > pretty simple addition, and no one is forced to use it, so I'm only asking
> > to understand better.
> Yes, I think its just another way to sample a large array. ISTR dbx allows
> printing array slices in this way.
And is this behaviour particularly useful?
> > > 2008-04-27 Nick Roberts <firstname.lastname@example.org>
> > >
> > > * mi/mi-cmd-var.c (mi_cmd_var_list_children): Add options to select
> > > a subset of children.
> > >
> > > * varobj.h (varobj_list_children): Declare new parameters.
> > >
> > > * varobj.c (struct varobj): New member current_children.
> > > (varobj_list_children): Create any new varobjs for children
> > > specified by mi_cmd_var_list_children.
> > > (create_child): Add parameter real_index. Use it.
> > >
> > I have a concern about the ordering of children. I think not having a
> > constant ordering for the children could prove a problem. For example, I
> > think the algorithm proposed will fail if a child varObj is deleted by the
> > user. I believe deleting a varObj inserts NULL in its current position,
> > however, the algo always inserts at the end, so it will miss the available
> > deleted entry.
> You're probably right about ordering, and deletion does cause a segmentation
> > Also, the double loop may prove to be slow for large number of children.
> I was thinking that only a small number of children would ever exist
> simultaneously. Scrolling might make that a larger number but maybe
> it could be arranged to delete children that go out of view.
I wonder if deleting children that are not visible is possible/desirable.
In Qt, item data is requested only when item is drawn. I think SWT's Tree can be
configured the same way. However, I don't think I saw any way, in either, to
detect than an item is no longer visible. Marc, can you tell if SWT allows that?
Even if technically possible, is this a desirable thing? I think the the primary
goal of incremental fetch is that if you happen to have std::vector with 200 children,
then display of it won't fill your entire screen with children of a single variable.
With incremental fetch, you can look at the children only if you're really interested.
On the other hand, I don't think keeping 200 varobjs in GDB is too expensive. And if
we talk about 10000 children, then well, I don't think standard variable display widget
is gonna be very good. Even if you delete varobjs that are not visible, it's too hard
to find anything interesting among 10000 elements.
> > I was thinking that we could keep order of children as they are defined
> > (current behaviour) but not fill them all, until requested.
> > We could create the full Vector of children as is done now by
> > while (VEC_length (varobj_p, var->children) < var->num_children)
> > VEC_safe_push (varobj_p, var->children, NULL);
> I guess this would remove the need for a second loop but it seems wasteful on
> memory. Previously children variable objects were stored as a linked list and,
> as I have said before, I do think this is more suitable as objects can then be
> inserted and removed at any point in the sequence of children.
Please feel free to implement generic list datastructure in C, or rewrite gdb in C++.
So far, using vector proved to be big convenience.
> > but only actually create the children that have been requested by the user.
> > I'm not sure how much efficiency there is by allocating the memory before
> > hand? Also, is there no way to grow the vector by more than a single point
> > at a time?
> Like resize with STL vectors? I'm not aware of one.