Le 20/12/2013 00:47, ed a écrit :
On Thursday, 19 December 2013 at 22:07:52 UTC, Dmitry Olshansky wrote:
20-Dec-2013 01:35, Xavier Bigand пишет:
Hi,
It's been a few months since I work on "DQuick" at a rate of a few
minutes or hours from time to time. After working professionally with
Java during a year I was really surprise to see D capable to compete a
such language on productivity and providing much more features than C++.
But because D and his compiler aren't as mature as c++ compilers, it can
be really hard to debug our code, mainly when searching memory issues,
because generated code by DMD isn't compatible with existing tools
(Valgrind, DrMemory).
At least valgrind works just fine for me. If compiled with debug
symbols callgrind works quite well, and so do the other tools e.g.
massif.
If I compile with -gc I have very little problem debugging my D code.
I regularly use valgrind and except for the occasional issue with
valgrind's crappy floating point support it works fine.
For general debugging I find GDB handles D more than well enough. There
are some minor issues, but nothing yet that is a show stopper. Because
GDB on the terminal is ugly I find Nemiver or QtCreator work fine as
front-ends, the latter requiring some initial config.
Very rarely GDB will get it so wrong that it won't be able to show the
value of a variable automatically. When that happens I still have the
address, type and size of the variable. From that it is then trivial to
set up a watch expression.
Occasionally when stepping source code GDB will appear step backwards. I
get this with C++ as well and it has never been an issue for me.
GDB issues aren't blockers like you say, but with valgrind I always have
floating point issue I don't know how to work around.
Maybe having a lot of initialization step in "static this()" of modules
can put some tools in difficulties?
DQuick load some dynamic libraries in that way.
