Re: exceptions
On Sep 18, 11:24 am, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
[...]
and an exception is thrown inside the constructor. Is it guaranteed
that c will be null?
Yes.
Are you sure?
Yes.
It's what I would expect, and it might be the
intent of the standard, but I don't think that the standard
actually guarantees it anywhere. I can't find anything in the
standard which guarantees that the pointer will not be modified
until after the return from the constructor; formally, at least,
a compiler could break the statement with the new down into:
c = operator new( sizeof( C ) ) ;
c->C() ; // Call the constructor.
(Note that if the constructor exits via an exception, the memory
will be freed. which would mean that c would end up containing
an invalid pointer.)
AFAICS that's right, there's a missing formal guarantee.
Then how are you sure:-)? It looks more to me as if you're
taking your desires for reality.
What's missing is a definition of built-in = in terms of a
built-in operator= function.
That's a generality with regards to operators. The built-in
operators do NOT generally create a sequence point. User
defined operators always do, because they are functions, and
calling a function creates a sequence point.
Regarded as a function, it's clear that the arguments are fully
evaluated before the function is called.
*Because* calling a function creates a sequence point.
Otherwise: an expression has a value and side effects. What the
standard guarantees is that the value is evaluated before it is
used, and that the side effects will not occur before any
previous sequence point, nor after any following sequence point.
The only ordering guarantees concerning side effects involves
sequence points.
If this is important, the obvious solution is:
try {
c = 0 ;
C* tmp = new C(...) ;
c = tmp ;
// ...
} catch ( E& e ) {
// ...
}
If c is a smart pointer, the original code should also work,
since the assignment operator is actually a function call, and
thus introduces a sequence point.
No, I don't think doing anything in-practice is a solution to
a purely formal problem, and absolutely not obvious. :-)
Is the problem purely formal? I originally believed that the
intent of the standard was probably to guarantee this, and that
the authors simply forgot to consider the case. On rereading
the clauses, however, I see that the possibility of a new
expression being interrupted by an exception definitly was
considered, so I'm beginning to think that the intent was to
leave this undefined. And if that was the intent, it's probable
that somewere, some compiler exploits this liberty.
More to the point, of course: this isn't really the way
exceptions were meant to be used. What I'd really expect to
see, in good code, is something like:
try {
C* c = new C( ... ) ;
// use c here...
} catch ...
If the code is more complicated, then it probably belongs in a
separate function, something like:
C*
createC( ... )
{
try {
return new C( ... ) ;
} catch ( E& e ) {
// ...
return NULL ;
}
}
--
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