Re: Interpretation of Effects in the C++ standard
Daniel Kr?gler wrote:
Greg Herlihy schrieb:
In the case of vector::assign(), it is clear that the Standard intends
that none of the existing elements in the destination vector are to be
assigned a new value. So it is important for assign() to fulfill that
implicit promise and make sure that the existing objects are deleted
before the copied objects are inserted. Assigning to other containers
may of course have different effects. For example, the proposed
optimization could be used to implement assign() for std::list.
OK, but lets consider the following scenario: An implementor of a
*sequence* container considers to implement the above mentioned
assign function as follows (In the snippet below this_type represents
the actual container type):
tempate <class InputIterator>
void assign(InputIterator first, InputInterator last) {
this_type(first, last).swap(*this);
}
Is this implementation conforming or not?
Certainly not. Consider the following:
std::vector< int > v ;
v.reserve( 200 ) ;
static int i[] = { 1, 2, 3 } ;
v.assign( i, i + 3 ) ;
std::vector< int >::iterator iter = v.begin() + 2 ;
for ( i = 4 ; i < 100 ; ++ i ) {
v.push_back( i ) ;
}
At this point, the standard requires iter to still be valid.
Your version of assign would break this.
I can see at least two arguments, which would make it invalid, if the
as-if-rule is taken literally:
1) insert (or its corresponding internal counterpart) is called before
any destructor of the current elements is called. (This is
theoretically an observable behaviour)
Your implementation fails even with trivial destructors.
2) If the now primary insertion fails, the *complete* operation has
*no* effect on the container elements, while the demanded
*observable* effect according to the standard's effect clause would
be that container is empty.
This conclusion can be drawn, because the corresponding clear
function is not allowed to throw and a exception-failing insert call
shall have no effect (see 23.1 p.10)
That's another good point.
Please note that there already exist a corresponding defect report
with WP state for std::list:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#320
But I wonder why this defect report is limited to list, because it
should be possible (as shown above) to implement it for all standard
containers due to the requirements on swap.
Constraints on iterators make this implementation invalid on all
but list, I think.
I further wonder, why the assign function is not part of the container
or sequence requirements. Can someone enlighten me concerning
this?
A priori, because it isn't required:-). In the case of
containers in general, I'd say that this is correct. Containers
are not required to support insert, and may have a fixed size,
so you cannot assign an arbitrary sequence to them. In the case
of sequences... it is required, at least in the current draft.
--
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! ]