Emacs 22.1 has a graphical interface to Gdb which allows the display of
watch expressions in the Speedbar.
Using variable objects, if I display a watch expression for an STL container
in a program compiled with gcc, e.g.,
vector<int> v (3);
v[0] = 1;
v[1] = 11;
v[2] = 22;
in the Speedbar, I get something like this:
v std::vector<int,std::allocator<int> >
std::_Vector_base<int,std::allocator<int> >
std::_Vector_base<int,std::allocator<int> >
public
_M_impl std::_Vector_base<int,std::allocator<int> >::_Vector_impl
std::allocator<int> std::allocator<int>
__gnu_cxx::new_allocator<int> {...}
public
_M_start int * 0x804c008
*_M_start 0
_M_finish int * 0x804c014
*_M_finish 135153
_M_end_of_storage int * 0x804c014
*_M_end_of_storage 135153
which is a bit meaningless to the end user. In this case, I know where the
values are really stored:
v._M_impl._M_start int * 0x804c008
*v._M_impl._M_start 1
*(v._M_impl._M_start+1) 11
*(v._M_impl._M_start+2) 22
(gdb) p v._M_impl._M_finish - v._M_impl._M_start
$1 = 3
and it would be better for Emacs to display some of these.
However, _M_impl, _M_start etc are gcc internals and it might be risky for
Emacs to rely on them. Can anyone say how likely these internals are to
change? I'm not asking for a guarantee. It would be helpful just to know
when they last changed as an indication of how volatile this code might be.
--
Nick http://www.inet.net.nz/~nickrob
