This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[patch 0/4] varobj_list replacement [Re: [patch 4/8] Types GC [varobj_list to all_root_varobjs]]
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Vladimir Prus <vladimir at codesourcery dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, gdb-patches at sourceware dot org
- Date: Fri, 10 Jul 2009 22:11:04 +0200
- Subject: [patch 0/4] varobj_list replacement [Re: [patch 4/8] Types GC [varobj_list to all_root_varobjs]]
- References: <20090525080233.GD13323@host0.dyn.jankratochvil.net> <m3ljo1i125.fsf@fleche.redhat.com> <20090702083705.GA14783@host0.dyn.jankratochvil.net> <200907021409.39886.vladimir@codesourcery.com>
On Thu, 02 Jul 2009 12:09:39 +0200, Vladimir Prus wrote:
> Can we just make varobj.c expose vector of varobjs?
In general iterators are preferred over direct variable access in modern
programming. It makes the implementation free to change the underlying data
structures to always use algorithms with optimal complexity.
Specifically the VEC structure (contiguous array) is not well suited as:
* It cannot effectively insert/remove elements while keeping the original order.
* Iterating such VEC while it is being changed is difficult.
* Current varobj_delete + install_variable API does not report the number of
successfully deleted/inserted root items to make such iteration safe.
There are at least ways of implementing there the VEC:
VEC_safe_push + VEC_unordered_remove:
+ It is algorithmically optimal complexity.
- It no longer keeps the root variables order - this breaks the testsuite.
Verified all the FAILs are just an order change having no real regressions.
I will fix the testsuite if it gets approved this way.
I believe frontends do not depend on the ordering, I would test
Eclipse+Nemiver or some others upon recommendation.
- Difficult to keep iterating the VEC being changed
by varobj_delete + install_variable in the meantime.
varobj_delete + install_variable API change may be more appropriate.
VEC_safe_insert + VEC_ordered_remove:
+ It keeps the root variables in the current order.
+ It has no testsuite changes / regressions.
- It is ineffective (two memmove calls per varobj_invalidate per rootvar).
- Difficult to keep iterating the VEC being changed
by varobj_delete + install_variable in the meantime.
* Guess the index / placement will match one remove + insert
or
* Extend the varobj_delete + install_variable API to return the exact number
of removed and inserted rootvars.
Still I would prefer:
Iterator - so-called "safe" (keeping the next pointer) double link list:
+ It is algorithmically optimal complexity.
+ It keeps the root variables in the current order.
+ It has no testsuite changes / regressions.
+ More simple usage at the caller (no varobj_root_get_var).
+ Separates the interface and implementation parts.
+ Easy iterating the list being changed by varobj_delete + install_variable
in the meantime. One just keeps the "next" pointer before calling them.
Regression tested all the 4 patches on {x86_64,i686}-fedora-linux-gnu.
Thanks,
Jan