build pretty-print of STL at the language level rather than debugger level...
84 views
Skip to first unread message
wm201...@gmail.com
Dec 22, 2016, 11:45:17 AM12/22/16
to ISO C++ Standard - Future Proposals
build pretty-print of STL at the language level rather than debugger level...
Here's a worthy standard's improvement. adding a special grammer to C++ classes for specifying the pretty-print STL format to the debugger before compilation rather than after compilation with the "printers.py gdb bandaid".
That's the real reason STL containers stink. You can't see anything when debugging because the
"pretty printers" is always broken or misconfigured for your compiler and really its only a kludge where there are better ways to solve the problem... such as marking the fields to export to the debugger "pretty printer". if only they would just tag the "char*" buried 3 levels down in the container as a "pretty printer" export to the debugger to show first...before digging into the ugly details of the data structure.
Like some type of syntax in the language to self-document how the date in the underlying structure of the container should be presented to the debugger and that has no real purpose in the code other than documenting.
Crude example:
class mycontainer {
public:
int junk field1;
int junk field2;
string fields3;
objx obj3[10];
pretty_printers:
char* field3 : obj3[3]->obj4.mychar;
char* field1 : obj3[1]->obj4->obj3423->mychar;
}
debugger watch window:
mycontainer char* x.field3
mycontainer char* x.field1
<click to expand full ugliness>
Here's a worthy standard's improvement. adding a special grammer to C++ classes for specifying the pretty-print STL format to the debugger before compilation rather than after compilation with the "printers.py gdb bandaid".
That's the real reason STL containers stink. You can't see anything when debugging because the
"pretty printers" is always broken or misconfigured for your compiler and really its only a kludge where there are better ways to solve the problem... such as marking the fields to export to the debugger "pretty printer". if only they would just tag the "char*" buried 3 levels down in the container as a "pretty printer" export to the debugger to show first...before digging into the ugly details of the data structure.
Like some type of syntax in the language to self-document how the date in the underlying structure of the container should be presented to the debugger and that has no real purpose in the code other than documenting.
Crude example:
class mycontainer {
public:
int junk field1;
int junk field2;
string fields3;
objx obj3[10];
pretty_printers:
char* field3 : obj3[3]->obj4.mychar;
char* field1 : obj3[1]->obj4->obj3423->mychar;
}
debugger watch window:
mycontainer char* x.field3
mycontainer char* x.field1
<click to expand full ugliness>
Nicol Bolas
Dec 22, 2016, 12:25:55 PM12/22/16
to ISO C++ Standard - Future Proposals, wm201...@gmail.com
No. We should not add C++ syntax explicitly and solely for dealing with compiler/debugger issues.
Ville Voutilainen
Dec 22, 2016, 12:32:30 PM12/22/16
to ISO C++ Standard - Future Proposals
On 22 December 2016 at 19:25, Nicol Bolas <jmck...@gmail.com> wrote:
> No. We should not add C++ syntax explicitly and solely for dealing with
> compiler/debugger issues.
..and I would expect it to be quite doable to add fairly sane
> No. We should not add C++ syntax explicitly and solely for dealing with
> compiler/debugger issues.
pretty-printers with reflection, once we get there.
Furthermore, such syntax doesn't go very far since it's
implementation-specific to quite an extent what it will
print. And how any pretty-printers tie into different debuggers is a
completely separate problem to solve.
Reply all
Reply to author
Forward
0 new messages