What are the worst parts of D?

[H. S. Teoh via Digitalmars-d]

On Wed, Sep 24, 2014 at 10:30:49PM -0700, Walter Bright via Digitalmars-d wrote:
> On 9/24/2014 9:43 PM, H. S. Teoh via Digitalmars-d wrote:
> >printf debugging FTW! :-P
> 
> There's more than that, but yeah. Most of my types I'll write a
> "pretty printer" for, and use that. No conceivable debugger can guess
> how I want to view my data.
> 
> For example, I can pretty-print an Expression as either a tree or in
> infix notation.

gdb does allow calling your program's functions out-of-band in 'print'.
I've used that before when debugging C++, which is a pain when lots of
templates are involved (almost every source line is demangled into an
unreadable glob of <> gibberish 15 lines long). Wrote a pretty-printing
free function in my program, and used `print pretty_print(my_obj)` from
gdb. Worked wonders!

Having said that, though, I'm still very much a printf/writeln-debugging
person. It also has the benefit of working in adverse environments like
embedded devices where the runtime environment doesn't let you run gdb.


> >I don't agree with that. I think symbolic debuggers should be
> >improved so that they *can* become useful with high level
> >abstractions. For example, if debuggers could be made to understand
> >templates and compile-time constants, they could become much more
> >useful than they are today in debugging high-level code.
> 
> The fact that they aren't should be telling. Like maybe it's an
> intractable problem :-) sort of like debugging optimized code.

When all else fails, I just disassemble the code and trace it along
side-by-side with the source code. Not only it's a good exercise in
keeping my assembly skills sharp, you also get to see all kinds of
tricks that optimizers nowadays can do in action. Code hoisting,
rearranging, register assignments to eliminate subsequent loads,
vectorizing, etc.. Fun stuff.  Not to mention the thrill when you
finally identify the cause of the segfault by successfully mapping that
specific instruction to a specific construct in the source code -- not a
small achievement in this day and age of optimizing compilers and
pipelining, microcode CPUs!

Nevertheless, I think there is still room for debuggers to improve.
Recently, for example, I learned that gdb has acquired the ability to
step through a program backwards. Just missed the point in your program
where the problem first happened? No problem, just step backwards until
you get back to that point! Neat stuff. (How this is implemented is left
as an exercise for the reader. :-P)


T

-- 
Stop staring at me like that! It's offens... no, you'll hurt your eyes!