vector.swap and heap / stack

S

Steve Hill

Hi,
suppose I have a vector allocated on the heap. Can I use a temporary
(stack based vector) and swap to clear it, or is this unsafe. e.g.

vector<int> *v;
vector<int> tmp;
v->swap(tmp); // is this an unsafe transfer between heap and stack
// or does the allocator handle it safely?


regards,
steve
 
I

Ivan Vecerina

| suppose I have a vector allocated on the heap. Can I use a temporary
| (stack based vector) and swap to clear it, or is this unsafe. e.g.
|
| vector<int> *v;
| vector<int> tmp;
| v->swap(tmp); // is this an unsafe transfer between heap and stack
| // or does the allocator handle it safely?

It is safe.
You could write:
void clearV(vector<int>& c)
{ vector<int>().swap(c); }

And call it with various instances:

auto_ptr<vector<int> > p = new vector<int>(4,5);
clearV( *p );

vector<int> l(4,5);
clearV( l );

static vector<int> s(4,5);
clearV( s );

All is safe and sound...

hth
 
I

Ivan Vecerina

Mike Wahler said:
Yes, this is safe. But note that you needn't define
'tmp', you could use a temporary expression:

v->swap(std::vector<int>());

This line is actually illegal in standard C++, unlike:
std::vector<int>().swap(*v); // this is ok

A temporary can only be bound to a *const* reference,
while the parameter of swap is a non-const reference.
(MSVC typically supports the line you posted as an
extension of the language, but it is non-standard).
BTW, why not just use the 'clear()' member function:

v->clear();

Because clear does not free the memory allocated by *v,
while using the swap trick typically will (although
the standard does not formally guarantee this).


Regards,
Ivan
 
I

Ivan Vecerina

Mike Wahler said:
Actually, I didn't mean either one.

I meant:

std::swap(*v, std::vector<int>());

Note that this illegal, for the same reason as the
first example ( v->swap(std::vector<int>()) ).
std::vector<int>() is a temporary, and both of the swap
calls you suggested expect a non-const reference as a
first parameter.
This is unlike the valid option:
std::vector<int>().swap(*v); // this is ok
Here swap is invoked as a member function of the
temporary, which is legal ISO C++.
AFAIK, it *will* free the memory occupied by
its elements (assuming of course that if the
elements are UDT's which manage memory, they do so
correctly).

The standard mandates that v.clear() is equivalent to
calling v.erase( v.begin(), v.end() ) -- in 23.1.1.
The erase function does not cause the vector's memory
to be reallocated (or freed). Its effect is to (23.2.4.3)
invalidate "all the iterators and references *after* the
point of the erase". Which means that the iterator
returned by v.begin() shall not be invalidated by the
call to v.clear().
Basically, clear() will set the *size* of a vector to 0,
but will leave the *capacity* of the vector unchanged.
The memory block that std::vector has allocated to
store its contents will not be freed.
Can you elaborate, please?

v1.swap(v2) will exchange the memory blocks that are
associated with the two vectors. This is typically done
by swapping the pointers stored within each vector.

When using: std::vector<int>().swap(*v);
std::vector<int>() typically does not allocate any
memory (its capacity is zero). After the memory blocks
are exchanged, v will receive the block of capacity 0,
and the temporary owns the memory previously associated
with v -- which will be released by the temporary's
destructor.

Well, I hope this is not too confused... it's getting
late here.

Sincerely,
Ivan
 
I

Ivan Vecerina

| On Thu, 21 Aug 2003 01:37:01 +0200, "Ivan Vecerina"
| <ivecATmyrealboxDOTcom> wrote:
|
| >The standard mandates that v.clear() is equivalent to
| >calling v.erase( v.begin(), v.end() ) -- in 23.1.1.
| >The erase function does not cause the vector's memory
| >to be reallocated (or freed). Its effect is to (23.2.4.3)
| >invalidate "all the iterators and references *after* the
| >point of the erase". Which means that the iterator
| >returned by v.begin() shall not be invalidated by the
| >call to v.clear().
|
| It certainly shall! erase invalidates iterators to erased elements, as
| well as iterators to elements after the erase.

From my reading of the standard (see the *after* above),
I believe that the following is legal code:

void deleteOddValues(std::vector<int>& v)
{
std::vector<int>::iterator scan = v.begin();
while( scan != v.end() )
if( *s % 2 ) v.erase(scan);
else ++scan;
}

The iterator from which the erasing starts remains valid
(although it must not be dereferenced if it now equals end()).

By extension, the following should also be ok:
std::vector<int>::iterator b = v.begin();
v.clear();
assert( b == v.end() && b == v.begin() );

Therefore, v.clear() cannot free the memory occupied by
the vector (the allocator's interface doesn't support
in-place shrinking of allocated memory).
And the std::vector<int>().swap(v) trick has its place...


Kind regards,
Ivan
 
T

tom_usenet

| It certainly shall! erase invalidates iterators to erased elements, as
| well as iterators to elements after the erase.

From my reading of the standard (see the *after* above),
I believe that the following is legal code:

void deleteOddValues(std::vector<int>& v)
{
std::vector<int>::iterator scan = v.begin();
while( scan != v.end() )
if( *s % 2 ) v.erase(scan);
else ++scan;
}

The iterator from which the erasing starts remains valid
(although it must not be dereferenced if it now equals end()).

By extension, the following should also be ok:
std::vector<int>::iterator b = v.begin();
v.clear();
assert( b == v.end() && b == v.begin() );

Therefore, v.clear() cannot free the memory occupied by
the vector (the allocator's interface doesn't support
in-place shrinking of allocated memory).
And the std::vector<int>().swap(v) trick has its place...

Apologies, you're correct according to the standard, if not according
to my expectations (although they have now been updated).

Tom
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top