exceptions

[dragonslayer008]

If you have code like:

try
{
c = 0; // initialize
c = new C(...); // c of type C*
}
catch( E& e)
{
...
}

and an exception is thrown inside the constructor. Is it guaranteed
that c will be null?

 

[AnonMail2005]

If you have code like:

try
{
c = 0; // initialize
c = new C(...); // c of type C*}

catch( E& e)
{
...

}

and an exception is thrown inside the constructor. Is it guaranteed
that c will be null?

Yes. The assignment must come *after* the creation of the object.

 

[Alf P. Steinbach]

* (e-mail address removed):

If you have code like:

try
{
c = 0; // initialize
c = new C(...); // c of type C*
}
catch( E& e)
{
...
}

and an exception is thrown inside the constructor. Is it guaranteed
that c will be null?

Yes.

However, most likely the construction above is an attempt to solve a
problem in a cumbersome way.

If you posted the Real Problem(TM), you would probably bet getter advice
than a simple confirmation that the code above "works".

Cheers, & hth.,

- Alf

 

[James Kanze]

* (e-mail address removed):

Yes.

Are you sure? 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.)

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.

 

[Alf P. Steinbach]

* James Kanze:

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.

What's missing is a definition of built-in = in terms of a built-in
operator= function.

Regarded as a function, it's clear that the arguments are fully
evaluated before the function is called.

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.

Cheers,

- Alf

 

[James Kanze]

* James Kanze:

[...]

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.

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 ;
}
}

 

[Alf P. Steinbach]

* James Kanze:

* 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?

From understanding the language and the intent of the standard, which
is sufficiently trivial in this case that even I manage it.

In short, built-in "=" Shall Have No Side-Effects If An Operand Throws.

It's the same principle that evaluating 2+5 doesn't change any variable,
although AFAIK the standard doesn't forbid that... Unreasonable things
that aren't explicitly disallowed are not implicity allowed. They're
implicitly disallowed.

It looks more to me as if you're
taking your desires for reality.


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.

For your convenience I now searched up (took about 5 seconds) relevant
core language issues, and it seems there's only one, <url:
http://std.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#222>.

In a way you're right to /associate/ this with sequence points.

But you're also, IMHO, wrong: it doesn't /necessarily/ have to do with
sequence points in the expression, although that's what the committee,
IMO unfortunately, landed on at the end for issue 222.

Andrew Koenig, who posted the original 222 DR, argued that "[treating =
as a function operator=] might be overkill: I see no reason to require
that in x[i++] = y;". But then AIUI issue 222 has to do with the order
things happen in just before returning an lvalue, not the order things
happen in before storing a value. I.e. it has not to do with side
effects in the face of exceptions, but it illustrates very clearly that
the current wording is not defining the intended semantics rigorously.

As of November 2006 the draft wording was "In simple assignment (=), the
value of the expression replaces that of the object referred to by the
left operand.", which crucially brings in "value of the expression", but
it seems to me that the committee still hasn't considered your point.

Cheers, & hth.,

- Alf