Re: We do not use C++ exceptions
on Wed Jan 21 2009, Andrei Alexandrescu <SeeWebsiteForEmail-AT-erdani.org> wrote:
Le Chaud Lapin wrote:
On Jan 14, 12:36 pm, Mathias Gaunard <loufo...@gmail.com> wrote:
On 14 jan, 01:23, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
if (arg < 0)
perror ("Negative value passed to function when positive value
expected!!!"); // silly, IMO :)
They simply don't know about assert(arg >= 0).
Making arg unsigned could also have been a solution (or not).
I think it is. This goes along with the philosophy that part of being
a good engineer is structuring the system so that certain awkward
questions never need be asked:
Brilliantly stated!
Hm, I'd have a couple of comments to these questions. To me it doesn't
quite feel the answer to them is universally agreed upon by good engineers.
That's true, but even good engineers can be wrong :-)
Q: What happens when value of this inherently positve argument is
negative? Should I assert?
A: You should not have declared it int. Make it unsigned int.
Unfortunately, that's not going to help that much. Due to C and C++'s
proneness to automatically convert any integral with a pulse to any
other integral with a pulse, unsigned is not much useful as a model of
natural numbers. (I owe understanding of this fact to Gabriel Dos Reis,
and it was one of the latest things I'd learned about C++, which may be
evidence for its subtlety.)
It doesn't help that much for overall system reliability if you're
trying to make it resilient against programmer errors, but personally I
think that approach is a dead end. Systems that try to be resilient
quickly become messy and unmaintainable due to the extra resiliency
code, which can almost never be properly tested. Rather, I prefer to
concentrate on making it less likely that programmer errors will occur,
and one way to do that is to build as much information about
preconditions as possible into the parameter types.
Using unsigned pushes the question to the boundary between the function
and its caller rather than allowing the question to occur inside the
function where it complicates code. Callers of functions already need
to understand the relationship between argument and parameter types and
watch out for narrowing conversions (which occur even with signed
types), so it doesn't make for a new point of unreliability.
Q: How do I return an error code from a constructor if exceptions are
not available:
A: You should use exceptions.
That's negating the hypothesis :o).
Nice trick, eh?
Q: My 2-month old new and fancy universal deep-copy framework is not
quite right though I have exerted Hurculean effort to make it such.
What should I do?
A: Rethink the very notion of "deep copy".
Nice!
Funny you should say that. I've seen a video on google from a speaker
at Adobe that promoted the notion that all values should be deep
copyable,
Well, not exactly. The video (below) lays out an approach to
programming with _values_. I agree that we should rethink the notion of
"deep copy." There is only one notion of "copy" for _values_; you
simply can't have shallow and deep versions if you're going to preserve
equational reasoning. The stuff that's part of the value gets copied
(modulo implementation sharing due to immutability or COW -- you still
have a logical copy). But that's one of those things that none of the
other GC'd everything-is-a-reference languages seem to understand.
and that there should be no aliasing.
You can have implementation aliasing but no logical aliasing.
Does anyone know a pointer to that talk? It was called "Defining good
values" or something like that, but I couldn't find it again.
http://my.adobe.acrobat.com/p53888531/
It's a great talk; I recommend it to everyone.
Also download the pdf at
http://stlab.adobe.com/wiki/index.php/Papers_and_Presentations
Q: My 2-month old new and fancy C++ introspection framework will not
automate itself. I just know I am missing something because it happens
all the time in Java. Why won't these classes instrospect themselves?
Is C++ defective?
A: C++ is not Java or any other interpreter-assisted language. Think
very carefully about comparing C++ to something that is fundamentally
different from it. If you insist, define an object that is a
hierarchy, where each node of the hierarchy is a mapping of string to
an associative set of string to string. That's the best you're going
to get in C++.
Interpreted has nothing to do with it. It's about introspection, of
which Java has more than C++. I see nothing in C++ that makes it
fundamentally opposed to introspection capabilities.
I agree with you there, Andrei.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]