RE: [boost] Standard C Library and C++ / BOOST
Reece Dunn wrote: [snip]
A trick I use when handling HRESULT error codes is to have a class like this (adapted for int error type):
class errorcheck { [snip] public: inline errorcheck( int ec ): error( ec ) { if( ec < 0 ) throw( *this ); }
Careful. Throwing an exception from a constructor means that the object won't be constructed (i. e., does not exist). So you are throwing a non-existing object here. Or am I wrong? Best regards, Klaus
"Klaus Nowikow" <nowikow@decomsys.com> writes:
Reece Dunn wrote: [snip]
A trick I use when handling HRESULT error codes is to have a class like this (adapted for int error type):
class errorcheck { [snip] public: inline errorcheck( int ec ): error( ec ) { if( ec < 0 ) throw( *this ); }
Careful. Throwing an exception from a constructor means that the object won't be constructed (i. e., does not exist). So you are throwing a non-existing object here.
Or am I wrong?
You're wrong. *this is copied before it is thrown. Still, the idiom above seems a bit suspicious, unless you somehow prevent derivation from errorcheck. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Sat, 27 Mar 2004 19:23:50 -0500, David Abrahams <dave@boost-consulting.com> wrote:
"Klaus Nowikow" <nowikow@decomsys.com> writes:
Reece Dunn wrote: [snip]
A trick I use when handling HRESULT error codes is to have a class like this (adapted for int error type):
class errorcheck { [snip] public: inline errorcheck( int ec ): error( ec ) { if( ec < 0 ) throw( *this ); }
Careful. Throwing an exception from a constructor means that the object won't be constructed (i. e., does not exist). So you are throwing a non-existing object here.
Or am I wrong?
You're wrong. *this is copied before it is thrown. Still, the idiom above seems a bit suspicious, unless you somehow prevent derivation from errorcheck.
I can't believe you are justifying the above. You copy an object that doesn't exist yet! (The class is not a POD and has a non trivial constructor - and even if this wasn't the case...) Genny.
Gennaro Prota wrote:
On Sat, 27 Mar 2004 19:23:50 -0500, David Abrahams <dave@boost-consulting.com> wrote:
"Klaus Nowikow" <nowikow@decomsys.com> writes:
Reece Dunn wrote: [snip]
A trick I use when handling HRESULT error codes is to have a class like this (adapted for int error type):
class errorcheck {
[snip]
public: inline errorcheck( int ec ): error( ec ) { if( ec < 0 ) throw( *this ); }
Careful. Throwing an exception from a constructor means that the object won't be constructed (i. e., does not exist). So you are throwing a non-existing object here.
Or am I wrong?
You're wrong. *this is copied before it is thrown. Still, the idiom above seems a bit suspicious, unless you somehow prevent derivation
from errorcheck.
I can't believe you are justifying the above. You copy an object that doesn't exist yet! (The class is not a POD and has a non trivial constructor - and even if this wasn't the case...)
I don't see how the object is not fully initialized inside its constructor?? Could you explain your objection? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
On Sun, 28 Mar 2004 10:41:11 -0600, Rene Rivera <grafik.list@redshift-software.com> wrote:
I don't see how the object is not fully initialized inside its constructor?? Could you explain your objection?
You (all) decided to make an anticipated April fool? :) Genny.
From: Rene Rivera <grafik.list@redshift-software.com>
Gennaro Prota wrote:
On Sat, 27 Mar 2004 19:23:50 -0500, David Abrahams <dave@boost-consulting.com> wrote:
"Klaus Nowikow" <nowikow@decomsys.com> writes:
Reece Dunn wrote: [snip]
class errorcheck { [snip] public: inline errorcheck( int ec ): error( ec ) { if( ec < 0 ) throw( *this ); }
Careful. Throwing an exception from a constructor means that the object won't be constructed (i. e., does not exist). So you are throwing a non-existing object here.
Or am I wrong?
You're wrong. *this is copied before it is thrown. Still, the idiom above seems a bit suspicious, unless you somehow prevent derivation from errorcheck.
I can't believe you are justifying the above. You copy an object that doesn't exist yet! (The class is not a POD and has a non trivial constructor - and even if this wasn't the case...)
I don't see how the object is not fully initialized inside its constructor?? Could you explain your objection?
Until the ctor finishes -- after the closing } -- there is no object (see 3.8/1). -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart wrote:
From: Rene Rivera <grafik.list@redshift-software.com>
Gennaro Prota wrote:
On Sat, 27 Mar 2004 19:23:50 -0500, David Abrahams <dave@boost-consulting.com> wrote:
"Klaus Nowikow" <nowikow@decomsys.com> writes:
Reece Dunn wrote: [snip]
class errorcheck {
[snip]
public: inline errorcheck( int ec ): error( ec ) { if( ec < 0 ) throw( *this ); }
Careful. Throwing an exception from a constructor means that the object won't be constructed (i. e., does not exist). So you are throwing a non-existing object here.
Or am I wrong?
You're wrong. *this is copied before it is thrown. Still, the idiom above seems a bit suspicious, unless you somehow prevent derivation
from errorcheck.
I can't believe you are justifying the above. You copy an object that doesn't exist yet! (The class is not a POD and has a non trivial constructor - and even if this wasn't the case...)
I don't see how the object is not fully initialized inside its constructor?? Could you explain your objection?
Until the ctor finishes -- after the closing } -- there is no object (see 3.8/1).
Yes the object lifetime hasn't started... but the object is initialized. Which according to 12.7 allows for referring to members of the object directly or indirectly, in this case by a copy ctor function. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
From: Rene Rivera <grafik.list@redshift-software.com>
Rob Stewart wrote:
Until the ctor finishes -- after the closing } -- there is no object (see 3.8/1).
Yes the object lifetime hasn't started... but the object is initialized. Which according to 12.7 allows for referring to members of the object directly or indirectly, in this case by a copy ctor function.
A copy ctor requires an object to copy. Until the closing brace, there is no object. You can justify your actions by saying that all of the dms have been initialized and that the copy ctor is just accessing those dms via a pointer, but that doesn't change the fact that you're invoking a cctor with a non-object. (3.8/3) Pragmatically, what you've done should work fine on any compiler. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Gennaro Prota <gennaro_prota@yahoo.com> writes:
Careful. Throwing an exception from a constructor means that the object won't be constructed (i. e., does not exist). So you are throwing a non-existing object here.
Or am I wrong?
You're wrong. *this is copied before it is thrown. Still, the idiom above seems a bit suspicious, unless you somehow prevent derivation from errorcheck.
I can't believe you are justifying the above.
I'm not justifying it. I'm simply disagreeing with "you're throwing a non-existing object here". OK, construction has not yet completed, so it's a dubious practice, but the object surely exists at the point of the throw. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (5)
-
David Abrahams -
Gennaro Prota -
Klaus Nowikow -
Rene Rivera -
Rob Stewart