Re: One very confused question about the Item 13 in the book "Exceptional C++" by Herb
shikn wrote:
[Fixed quoting, please see to the configuration of your newsclient,
thanks.]
"Gene Bushuyev" <spam@spamguard.com> wrote in message
news:ii6bg.78369$H71.20548@newssvr13.news.prodigy.com...
"Gavin Yu" <songtaoyu@lucent.com> wrote in message
news:e4ghvu$jok$1@netnews.net.lucent.com...
I am one C++ lover and I encountered one very confused question
during
reading the Item 13 of the book "Exceptional C++" written by Herb
Sutter.
In the Item(Item 13), there are some words as below:
The Copy Constructor
Note that the Stack copy constructor does not call the StackImpl
copy
constructor.
(See the previous solution for a discussion of what construct()
does.)
Stack(const Stack& other)
: StackImpl<T>(other.vused_)
{
while( vused_ < other.vused_ )
{ construct( v_+vused_, other.v_[vused_] );
++vused_;
}
}
[...]
The idea is that StackImpl<T> ctor doesn't require objects of type T
copying, so it can only fail if raw memory allocation fails, in which
case no destruction is necessary. The functions construct() are
actually calling the copy ctor of T and can throw. When that happens
the subobject of StackImpl<T> type was already fully constructed and
thus when exception is thrown from Stack body the destructor for
subobject is called. StackImpl<T> destructor destroys all the
objects that were successfully copied.
[...]
Excuse me, I have question on this. How the compiler recognized the
objects in this raw memory are constructed or not?
If the initialization are in random sequence, such like,
while( vused_ < other.vused_ )
{ construct( v_+vused_, other.v_[vused_] );
++vused_;
++vused_;
}
Does destructor not execute to the unconstructed object?
Dose the compiler mark the object which has finished constructing?
How
does the compiler implement the parts of "15.2/2" ?
I don't know the book and its code, but:
The vector with the members (v_) and the number of elements (vused_)
are in
the baseclass, which, at that point, has already been fully
constructed and
so will have its destructor run in case of exceptions.
The trick is to split the 'normal' code
try {
while( vused_ < other.vused_ ){
construct( v_+vused_, other.v_[vused_] );
++vused_;
}
} catch(...) {
while( vused_)
--vused_;
destroy( v_+vused_);
}
throw;
}
in two parts, one being in the baseclass, the other in the derived. One
could say that this is a tricky way to use RAII, the baseclass being the
RAII object in this case. Also, it avoids code duplication because
the dtor
would, apart from re-throwing the exception, do the same.
Uli
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]