Re: [RFC] Variable objects for STL containers

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

 > There's something I don't understand, and maybe you can help clear
 > things up.  It seems like this approach is going down a path of
 > hardwiring a lot of knowledge into gdb.  Solving this just for STL
 > (and then only one version of STL) seems to be one piece of a general
 > problem, why pick an unscalable solution?

This is not any STL, but Gcc's STL.  Gdb and Gcc are both part of the GNU
project so should possibly have a special relationship.  By unscaleable, I
guess you mean not general.  Hardwiring is a worry but I have briefly discussed
this subject on the Gcc and been assured that the code used is quite stable.
It's also a matter of keeping Gcc developers informed about intended use of
Gcc internals.

 >                                           If the knowledge was in a
 > collection of dlopen'd .so (or some such), and users could provide
 > more, then that might be reasonable.

If you know how to do it, that would be an improvement.  Presumably it could
also be done at a later stage, adapting any hardwired solution.

 >                                      [Setting aside use of python for
 > this, I understand there is some pushback to going that route.  It'd
 > be cool if the python support used the same interface, then one could
 > have it both ways.   The python support is, of course, not just for
 > this and one wouldn't want python to plug into gdb in a piecemeal
 > fashion.  OTOH, if a clean solution could be found that let one solve
 > this with either C[/C++] or python then that might be very useful.]

I don't really understand how the python support will be implemented but I
don't see why variable objects for STL containers should require Python
libraries to be present.

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