This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: -var-update @
On Tuesday 01 April 2008 15:23:29 Marc Khouzam wrote:
>
> > As an example I don't need the 'intermediate level' of public/protected/private
> > information for C++ objects, since I do not want to display that anyway.
> > Yet I have to ask for --all-children, wait for the response, parse it, only to
> > discover that it cointains a, say, private and a public block, and ask again
> > for the 'real' children now. So that's two full roundtrips for what could be one...
>
> That is good example of something that would be nice to improve.
> Maybe having a -depth option to the var-list-children command?
I am rarely interested in seeing deeper levels 'immediately',
and if so, it's unlikely that I'd need the same level for all
children. Just having an option to skip the 'access' level
would be nice. The access information could even be listed
in the child items directly, so there would be no loss of
information for the frontend at all...
> In DSF, we always go to a full depth, so we have no real use for having to
> separately query at each level of children.
Honestly, the biggest improvement for me would be 'stateless MI',
i.e. basically '-evaluate-expression' and '-list-children' without
varobjects being created at all.
I live in a almost pure C++ enviroment, so I display a, say,
std::map<int, std::string> as a two-column table, not as
'a bunch of structures containing pointers to each other'
(no offense to std::map<> implementors implied ;-) ).
Stateful varobject do not really help e.g. for getting
a notification when a new key/value pair gets inserted, as
this can basically happen everywhere in the tree.
Of course, I do not expect gdb to do my job in interpreting
the raw structures, but as it stands, some of the available
operations are "too high level" for me as they try to help me
in a way (like automatically creating varobjects, or, say
returning "cooked" data for char* values) that I have a hard
time to "actively ignore" ;-)
Regards,
Andre'