Re: efficiency of vector of pointers.
On Oct 20, 12:17 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
James Kanze wrote:
On Oct 20, 4:34 am, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
[...]
v.clear() will _not_ deallocate the elements of the vector. It will ju=
st
call the trivial destructor for each int* stored. Consequently, a call=
to
v.clear() without going through v and calling delete on all the pointe=
rs
will leak memory big time.
Moreover, v.clear() is not guaranteed to deallocate any memory allocat=
ed
by the vector v. In particular, v.capacity() may or may not change.
v.clear() is guaranteed by the standard to not reduce the
capacity(), and so in practice will never deallocate memory
allocated by the vector itself.
Where would I find that in the standard?
Spread out all over the place, and specified very indirectly.
It's designed so that you'll miss it:-).
I only found that the semantics of clear() is defined as
erase( begin(), end() ). Regarding erase(), I did not find
any statement in the standard as to how it may or may not
affect the capacity. The closest provision I found is that
erase does not invalidate iterators before the erased range
and hence it will generally not cause reallocation (however,
that is vacuous when all elements are erased). Or is it just
by absence: it is not mentioned in the Effects clause that the
capacity could change, therefore it cannot change?
Sort of. In general, a function cannot do other things that
what is specified in its effects clause: you won't find anything
in the standard that directly forbids vector::clear() from
modifying some other vector, as well as the one its called on,
either. This is more or less implicite.
Now consider something like the following:
std::vector< int > v ;
for ( int i = 0 ; i < 10 ; ++ i ) {
v.push_back( i ) ;
}
v.reserve( 100 ) ;
v.clear() ;
for ( int i = 0 ; i < 10 ; ++ i ) {
v.push_back( i ) ;
}
std::vector< int >::iterator it = v.begin() ;
v.push_back( 100 ) ;
I would contend that that last line cannot invalidate it. The
fact that capacity is tightly linked to iterator validity, at
least when inserting, means that not modifying capacity except
when explicitly allowed is a very, very important guarantee in
the standard. Managing the validity of iterators is already
hard enough as is.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34