Basic swap trick for stl containers!!!! (very interesting, READ till the END!)

[puzzlecracker]

I am sure all remember the infamous 'swap trick' to actually clear the
content of a vector.

void somefunc(){

vector<SomeType>(st).swap(st);

}


Here we create a temprary variable that is populated with st elements
and do the swap...

My question is at which point will that temp variable be destroyed: at
the end of the function or the statement?

If it happens at the end of the function, then the swap trick for the
actual removal of >= n/2 elements is an exercise in futility, for total
storage won't ebb, but may increase!

Any thoughts?

 

[Axter]

I am sure all remember the infamous 'swap trick' to actually clear the
content of a vector.

void somefunc(){

vector<SomeType>(st).swap(st);

}


Here we create a temprary variable that is populated with st elements
and do the swap...

My question is at which point will that temp variable be destroyed: at
the end of the function or the statement?

If it happens at the end of the function, then the swap trick for the
actual removal of >= n/2 elements is an exercise in futility, for total
storage won't ebb, but may increase!

Any thoughts?

It happens at the statement level

 

[John Harrison]

I am sure all remember the infamous 'swap trick' to actually clear the
content of a vector.

void somefunc(){

vector<SomeType>(st).swap(st);

}


Here we create a temprary variable that is populated with st elements
and do the swap...

My question is at which point will that temp variable be destroyed: at
the end of the function or the statement?

Statement. There are cases where temporaries persist for longer, but
this isn't one of them.

If it happens at the end of the function, then the swap trick for the
actual removal of >= n/2 elements is an exercise in futility, for total
storage won't ebb, but may increase!

Any thoughts?

The swap trick depends on the assumption that the default constructor
for vector creates a vector with no storage allocated. The C++ standard
does not guarantee this.

john

 

[puzzlecracker]

Statement. There are cases where temporaries persist for longer, but
this isn't one of them.

john

John (or anyone else for that matter),

can you identify those cases? I cannot really think any of the top of
my head.

Thank

 

[John Harrison]

John (or anyone else for that matter),

can you identify those cases? I cannot really think any of the top of
my head.

Thank

In actual fact the standard talks about the end of the 'full expression'
which I guess most times means the same as statement.

Two cases where are temporary pesists beyond the end of the statement are

const T& t = T();

and

const T& t = some_func();

in these cases the temporary lasts as long as the reference.

john

 

[puzzlecracker]

In actual fact the standard talks about the end of the 'full expression'
which I guess most times means the same as statement.

Two cases where are temporary pesists beyond the end of the statement are

const T& t = T();

and

const T& t = some_func();

in these cases the temporary lasts as long as the reference.

john

In this case, calling a function that takes const T &

(Example:

somefunc<int>(5);

template <typename T>
void somefunc(const T& t);
),

and passing to it an Rvalue or an equivalent to what you assign above
to const variable would constitute this class of temporaries. Albeit,
it just another variation of what you had already said.

Does anyone know whether the standard mention this at all?

 

[John Harrison]

In this case, calling a function that takes const T &

(Example:

somefunc<int>(5);

template <typename T>
void somefunc(const T& t);
),

and passing to it an Rvalue or an equivalent to what you assign above
to const variable would constitute this class of temporaries. Albeit,
it just another variation of what you had already said.

Does anyone know whether the standard mention this at all?

It's discussed in section 12.2. The case of a temporary bound to a
reference parameter in a function call is explcitly mentioned, 'persists
until the completion of the full expression containing the call'.

john