Re: Defeating (N)RVO
Alberto Ganesh Barbati wrote:
Thomas Maeder ha scritto:
"peter koch larsen" <peter.koch.larsen@gmail.com> writes:
I am thinking about "renewing" an old system which did not use
exception and begin using exceptions. For that purpose I need to be
able to convert our current errorcodes to exceptions by throwing an
exception in the destructor (if the errorcode is not destroyed during
exception unwinding) in exactly those cases where the errorcode has not
been "inspected" by the program. The problem comes in situations such
as this one:
Side note: throwing destructors are very often a bad idea.
Agreed. The OP's design is dubious to say the least.
I don't know. There are special cases, in which the destructor
is used to trigger an exception (which would normally be
triggered otherwise). Such classes obviously are not for
general use, but an ErrorCode class isn't for general use---you
won't have arrays of them, nor member variables. Used
correctly, you should never do anything (and thus, never throw)
unless it has been read.
The problem is that if NRVO is in place and somefunc() failed the
check in inner will mark the errorcode examined which it isnt
really.
If the (non)invokation of the copy-constructor matters here, then I
agree with the other posters that it is badly written. IMHO
In fact I think that the OP's code works *only* when (N)RVO occurs, and
does *not* work otherwise. That's because if the optimization does not
occur then somefunc() may throw even before giving the caller the chance
to inspect the error code, because there is a temporary of type
ErrorCode that gets destroyed before somefunc() returns.
I'm not sure about the OP's code; he didn't post it, so we can't
know. But in the usual implementation of this sort of thing,
the unread status propagates, and copying an object counts as
reading it. (You can also use reference counting, as Daniel
Kr?ger suggests. It's a more robust solution, but significantly
more expensive as well, and rarely necessary.)
One solution I see is to rely on the "destructive copy"
behavior of std::auto_ptr, for example:
class ErrorCode
{
std::auto_ptr<ErrorInfo> error;
public:
ErrorCode() {} // success code
ErrorCode(/*...*/) : error(new ErrorInfo(/*...*/)) {}
// notice: implicit copy ctor will copy the auto_ptr
// with destructive copy semantic
~ErrorCode()
{
if(error.get() && !uncaught_exception())
throw whatever(*error);
}
bool ok()
{
if(error.get())
{
error.reset(); // discard error: it has been inspected
return false;
}
else
return true;
}
// even better:
std::auto_ptr<ErrorInfo> get_error()
{
return error; // will reset error automatically
}
};
A plus of using std::auto_ptr is that you can nicely pack your
error info into a class.
If I were going to be that complicated, I'd use a shared_ptr.
With a destructor object which checked that the error code had
been read. But in the past, I've always found that just
propagating the hasBeenRead flag, and counting copy as a read,
has been sufficient. (This generally means that hasBeenRead is
mutable. Which is consistent in so far as it is not part of the
value of the ErrorCode itself.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]