Hello,
I have been playing with gdb array watches and I have some questions to ask.
1) every watch has property "is_array", "array_start" and "array_count". When adding a watch [in watch window, "Add watch"],
these 3 properties are ignored completely [you call AddWatch with only name and WatchFormat, thus loosing array properties].
When you save the watches to the file, you forget these as well [and the formatting too]. Wouldn't be better to a) remember
array & formatting properties in a save file, b) mind the array properties when adding a watch?
2) there are 2 types of array watches -- "c style arrays" and "stl vectors". The c style arrays looks like "{1, 2, 3}" when received from gdb,
stl vectors looks like "{[0] = 1, [1] = 2, [2] = 3}" [they are being formatted by Parse_StlVector in gdb_types.script].
When using "stl vector", you see correct numbering. You can even set array_start to some value [2, for example] and leave array_cound=0, and you see only
elements from 2 to the end of the vector. With correct numbering. The only problem with stl_vector is, that when it has less than 8 [debugger/single_line_array_elem_count], it get's formatted like "[[0]=1,[1]=2,[2]=3]", which is quite unreadable.
More problems with "c style arrays occurs": 1) when you set array_start=nonzero, array_count=zero, the staring index is completely
ignored [not a display problem, you use the array_start only when array_count is nonzero [this is not the case when using stl vector,
the gdb scripts for stl vector works when start!=0, count==0]]. When array_start=nonzero, array_count=nonzero, the data are
correct, but the numbering is not [it is always from zero, see line 400 in debuggertree.cpp.] But if you change the line 400 to the "correct"
array_index=watch->array_start
, the numbering stops working for array_start=nonzero, array_count=zero case.
Maybe the correct line should be
array_index=(watch->array_count) ? watch->array_start : 0
.
But the question is, whether count 0 works well for c style arrays: the start is then really ignored, and it is confusing.
Isn't it quite weird to number both there arrays in a completely different way? Wouldn't it be better to number them consistently AFTER extracted
from the debugger [that is, to delete Parse_StlVector method]? It would solve the single-line version of stl vectors, it would be nice and systematical.
The only problem is, that case array_start!=0, array_cound=0 works now for stl vectors
and would not after the suggested change. [On the other way, if gdb returns an array after line "output p", then "whatis p" returns the SIZE of the array. So when array_count is 0, is_array is 1 and the array is a c-style, the size could be extracted from the m_type string [don't remember the correct name]].
3) Multidimensional arrays.
There is no numbering at all for them. But it is confusing. An idea -- i think the best way to display them is to consider them as "vectors of whatever" and display the "whatever" on a single line. The example is probably best: {{{1,2},{3,4}}, {{5,6},{7,8}}} as
[0] = {{1,2},{3,4}}
[1] = {{5,6},{7,8}}
This way would be consistent with the array properties -- they consider the array to be single-dimensional.
I suggest to consider all arrays singledimensional, even if the values are arrays or arrays of arrays. It would be most usable and readable for me and it is not difficult to code. But for there multidimensional arrays, i would disable single-line version.
The point 2) and 3) could be solved together by a minor rewrite of array watches code. But there are questions whether to support array_start!=0 array_count=0 for stl vectors and whether the "array elment on singleline always" attitude is desirable.
Have a nice day,
Milan Straka
