Community
Participate
Working Groups
When debugging the following code variables 'a' and 'b' are pretty printed but not expandable and variable 'c' is expandable but is not pretty printed. void test() { string a("my string"); string& b = a; string* c = &a; } a string 0x7fffffffc520 "my string" b string & 0x7fffffffc520 "my string" c string * 0x7fffffffc510 __gnu_cxx::__versa_string<char, std::char_traits<char>, std::allocator<char>, __gnu_cxx::__sso_string_base> __gnu_cxx::__versa_string<char, std::char_traits<char>, std::allocator<char>, __gnu_cxx::__sso_string_base> {...} __gnu_cxx::__sso_string_base<char, std::char_traits<char>, std::allocator<char> > __gnu_cxx::__sso_string_base<char, std::char_traits<char>, std::allocator<char> > {...} __gnu_cxx::__vstring_utility<char, std::char_traits<char>, std::allocator<char> > __gnu_cxx::__vstring_utility<char, std::char_traits<char>, std::allocator<char> > {...} _M_dataplus _Alloc_hider<std::allocator<char> > {...} _M_string_length size_t 9 union {...} {...} npos const size_t It would be nice if all tree variables were both, pretty printed and expandable.
All the pretty-printing is done by GDB (although it is possible that we override something by mistake for a particular expression...). Can you attach the gdb traces to see if GDB is returning the pretty printed variable? Thanks
(In reply to comment #1) Here is a relevant part of gdb trace: 145,792 26-stack-list-locals --thread 1 --frame 0 1 145,799 26^done,locals=[{name="a",value="\"my string\""},{name="b",value="\"my string\""},{name="c",\ value="0x7fffffffc490"}] 145,800 (gdb) 146,159 34-var-create --thread 1 --frame 0 - * a 146,159 35-var-create --thread 1 --frame 0 - * b 146,159 36-var-create --thread 1 --frame 0 - * c 146,544 34^done,name="var7",numchild="0",value="0x7fffffffc4a0 \"my string\"",type="string",thread-i\ d="1",displayhint="string",dynamic="1",has_more="0" 146,545 (gdb) 146,545 35^done,name="var8",numchild="0",value="0x7fffffffc4a0 \"my string\"",type="string &",thread\ -id="1",displayhint="string",dynamic="1",has_more="0" 146,545 (gdb) 146,545 36^done,name="var9",numchild="1",value="0x7fffffffc490",type="string *",thread-id="1",has_mo\ re="0" 146,545 (gdb) Even though gdb reports numchild="0" for a and b, we could still get more information by asking it for '&a' and '&b' in addition to 'a' and 'b'.
(In reply to comment #2) > (In reply to comment #1) ... > Even though gdb reports numchild="0" for a and b, we could still get more > information by asking it for '&a' and '&b' in addition to 'a' and 'b'. I think the cleaner solution would be to follow the approach of bug322365. In the JDT debugger you enable logical structures if you want to see the logical contents (as a client of your code would be interested in), and disable it in order to see the raw implementation members (because you are the implementer). I don't think you want to see both. In gdb world that means enable the pretty printer if the logical structure button is checked, or disable it if not.
(In reply to comment #3) > I think the cleaner solution would be to follow the approach of bug322365. In > the JDT debugger you enable logical structures if you want to see the logical > contents (as a client of your code would be interested in), and disable it in > order to see the raw implementation members (because you are the implementer). > I don't think you want to see both. > > In gdb world that means enable the pretty printer if the logical structure > button is checked, or disable it if not. The downside of using the "Show Logical Structures" switch is that is applies to the whole view, while the most common use case is that the user for some reason needs to drill down on one particular variable and prefers to see other variables in pretty-printed form.
One important use case is smart pointers. Currently, if a smart pointer class has a pretty-printer, it is not possible to examine the object the pointer points to. This is a major problem since smart pointers are very common.
(In reply to comment #5) > One important use case is smart pointers. Currently, if a smart pointer class > has a pretty-printer, it is not possible to examine the object the pointer > points to. This is a major problem since smart pointers are very common. Am I getting that right: there are pretty printers for smart pointer classes that don't return a child for the owned object? What good is such a pretty printer? I use a pretty printer even for plain pointers. Its mere purpose is to return a child of the actual implementation type. So I even can expand the members of the actual type instead of just the declared.
