Re: Books for advanced C++ debugging
On Jul 16, 11:34 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
On Jul 16, 2:09 am, James Kanze <james.ka...@gmail.com> wrote:
[...]
For most programs, we don't care about the speed.
Agreed, and with the current state of the C++ industry, C++ is
not the best language for every situation. Perhaps Java is be
more useful for most programs.
Only if you can accept a fairly low level of robustness.
This intrigues me. If you elaborate or point me to articles,
I'd love to read up on this. IMHO, I could probably write an
application faster in C++ and have it be "more correct" (aka
less testing / bug-fixing time), but the same probably isn't
true of the average developer.
I don't think it's possible in Java to reach the level of
robustness I generally require, regardless of the developer.
There are too many things that simply aren't possible, like
programming by contract (which means executable code in the
"interface", which Java doesn't allow), or RAII. Or simply
being able to abort on an assertion failure.
I think that there are pre-processors which resolve some of
Java's problems in this respect---I've heard of one for
programming by contract, for example, and I'd like to see
something like ESC/Java for C++ (and a couple of quick checks on
the web suggest that Java is evolving to address these
problems).
I'm just curious how you're defining "robustness".
Vaguely:-). Basically, just that the code is known to be
correct, to a certain point, and that any errors will be
promptly detected and can easily be fixed.
Are we talking real- time?
No.
Or correct in the face of errors?
Possibly. If you accept that the correct behavior in the case
of a programming error is to abort (which is usually a
requirement in my work), then it's impossible to write code with
this behavior in Java.
Stuff like how it's easier to leak file handles, other
non-memory resources? Or how it's exceedingly annoying and
difficult to write correct code in the face of "dispose" /
"close" / "release" calls which can throw exceptions?
Partially. The lack of RAII does make certain types of errors
more likely, or harder to prevent (and missing finally blocks
are a common error in Java).
Or are we talking about how it's impossible to write correct
code in the face of asynchronous exceptions?
I'm not too sure what you mean here. As far as I know, neither
Java nor C++ support what I would call an asynchronous
exception. On the other hand, the fact that you can't guarantee
a function to never raise an exception in Java does mean that
you can't write really exception safe code.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34