1) I didn't test it, but that condition is really weird. Why there is test for the same thing twice? Here is the test case:
TEST(CDBSingleLineStructPointer)
{
GDBWatch w(wxT("t"));
CHECK(ParseCDBWatchValue(w, wxT("struct t * 0x123456"));
CHECK_EQUAL(wxT("t*=0x123456"), w);
}
TEST(CDBSingleLineClassPointer)
{
GDBWatch w(wxT("t"));
CHECK(ParseCDBWatchValue(w, wxT("class t * 0x123456"));
CHECK_EQUAL(wxT("t*=0x123456"), w);
}
2) In my code there is functionality that
dereferences pointer on double click on variable. There is array of structures
struct s {
payload_t payload;
struct s* next;
} item1, item2, ...;
struct s array[] = {
item1,
item2,
...
};
Then I try dereference pointer
next in structure on index 0 I get
(*array.[0].next) instead of
(*array[0].next). This expression is not valid and gdb can't return right result.
3) I don't override user's choice because there is a condition that allows set parameters only 1st time. If my code overrides user's choice there is
watch->SetArray(true); what also overrides user's choice. But no. As I tested if I change properties of watch everything stay set according to my new choice. Only if watch format is
Undefined and it is array with size (
int array[29];) but
GDBWatch::IsArray returns
false everything is set to default. I hope it is understandable - my English and speech aren't good :-(
I changed
GDBWatch::GetFullWatchString into test if parent is array - hope it's OK now.
4) For me it is good. Can you provide some example when it is not watchable? Or it is issue of any specific platform?
I graphical representation of watches programmer can see
actual indexed item of array in bold. My idea is, if i know index and size of array I can check if index is not bigger than size of array. Then C::B warns programmer about it. There is some complications now and I want to do on automatic graph layout of oriented graphs so I return to this later, but I think is not good if size of array will be available anyway.
In my code, there is many changes, but these seem to be bugs and useful changes that affect functionality of C::B. But I want to find out if some of them is not intention (like "whatis &" issue) because there is no explanation in comments. That's why I put them here.