Bronek Kozicki wrote:
> C++ standard does not mention what happens with memory allocated inside
> vector when whole vector is being invalidated by following operation
> (clause 23.2.4.3/3) :
>
> v.erase(v.begin(), v.end());
>
>>From definition of function "reserve" (clause 23.2.4.2/2) it's assumed
> that erase will not free memory allocated by vector. But it's not stated
> explicitly in standard, thus this assumption is doubtful - especially
> when whole vector is being erased. Is it omission in standard or it's
> left unspecified on purpose (eg. to allow space optimization, but not
> require it) ?
> ...

If you read the specification of 'std::vector<>' carefully, you'll
notice that it appears that an attempt was made to explicitly declare
the situations when reallocation might occur (see, for example, the
description of 'std::vector<>::insert'). Since the specification of
'std::vector<>::erase' doesn't say that reallocation might take place,
it seems to be pretty logical to assume that it doesn't.

Another thing to pay attention to is that the specification guarantees
that no reallocation takes place on an "partial" erase, since all
references and iterators before the point of the erase are guaranteed to
remain valid. You seem to separate the "full" erase into some kind of
special case, while the standard doesn't do that. (Yes, I understand
that "full" erase will invalidate all iterators anyway and, therefore,
deallocation of the memory won't violate anything in this respect).

I'd agree if you said that both of the above arguments are rather
inconclusive. I'd also prefer the standard to be more explicit in this
respect.

--
Best regards,
Andrey Tarasevich

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Andrey Tarasevich wrote:

> Bronek Kozicki wrote:
>
> If you read the specification of 'std::vector<>' carefully, you'll
> notice that it appears that an attempt was made to explicitly declare
> the situations when reallocation might occur (see, for example, the
> description of 'std::vector<>::insert'). Since the specification of
> 'std::vector<>::erase' doesn't say that reallocation might take place,
> it seems to be pretty logical to assume that it doesn't.

All of the container specifications do this to define which operations
could invalidate iterators and if so, which iterators.  I don't think
the spec should be read into any more than that.

> Another thing to pay attention to is that the specification guarantees
> that no reallocation takes place on an "partial" erase, since all
> references and iterators before the point of the erase are guaranteed to
> remain valid. You seem to separate the "full" erase into some kind of
> special case, while the standard doesn't do that. (Yes, I understand
> that "full" erase will invalidate all iterators anyway and, therefore,
> deallocation of the memory won't violate anything in this respect).

And since the point of the erase when calling clear() is the first
element, no gurantees are made about what's done with the any of
element-memory used by the container.  So what actually happens is, of
course, implementation-defined.


Sean

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Of the four implementations I checked, one implementation deallocated memory
on vec.clear() (even after a call to reserve). But, it did not do so for
vec.erase(vec.begin(), vec.end()), possibly because its capacity was more
than the size.

Vishal

Bronek Kozicki wrote:

> C++ standard does not mention what happens with memory allocated inside
> vector when whole vector is being invalidated by following operation
> (clause 23.2.4.3/3) :
>
> v.erase(v.begin(), v.end());
>
> >From definition of function "reserve" (clause 23.2.4.2/2) it's assumed
> that erase will not free memory allocated by vector. But it's not stated
> explicitly in standard, thus this assumption is doubtful - especially
> when whole vector is being erased. Is it omission in standard or it's
> left unspecified on purpose (eg. to allow space optimization, but not
> require it) ?
>
> B.
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

C++ standard does not mention what happens with memory allocated inside
vector when whole vector is being invalidated by following operation
(clause 23.2.4.3/3) :

v.erase(v.begin(), v.end());

>From definition of function "reserve" (clause 23.2.4.2/2) it's assumed
that erase will not free memory allocated by vector. But it's not stated
explicitly in standard, thus this assumption is doubtful - especially
when whole vector is being erased. Is it omission in standard or it's
left unspecified on purpose (eg. to allow space optimization, but not
require it) ?


B.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri, 24 Oct 2003 21:16:44 +0000, Bronek Kozicki wrote:

> C++ standard does not mention what happens with memory allocated inside
> vector when whole vector is being invalidated by following operation
> (clause 23.2.4.3/3) :
>
> v.erase(v.begin(), v.end());

This statement will not free the memory occupied by the vector. Neither
will v.clear ();

You can use the swap hack to get that effect.

template <class Type>
void erase_vector (std::vector<Type>& temp)
{
   std::vector<Type> useless;
   useless.swap (temp);
}


Regards,
-Dhruv.








---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sat, 25 Oct 2003 17:57:55 +0000 (UTC), "Dhruv" wrote:
>> C++ standard does not mention what happens with memory allocated inside
>> vector when whole vector is being invalidated by following operation
>> (clause 23.2.4.3/3) :
>>
>> v.erase(v.begin(), v.end());
>
> This statement will not free the memory occupied by the vector. Neither
> will v.clear ();

Well, this is what I have learned from books already (BTW: thanks for
reminding vector<T>::clear). However it does not seem to be mentioned
anywhere in the standard. Did I miss something (in C++ standard), is it
omission, or it's left unspecified on purpose? In other words: are
standard library implementors allowed to actually free memory (and lower
capacity) of vector in standard conforming implementation of
vector<T>::erase and vector<T>::clear ? If no, why ?


B.

PS. there is a reason why I ask this question here, not on comp.lang.c++ :)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sun, 26 Oct 2003 19:28:48 +0000 (UTC), brok@rubikon.pl (Bronek
Kozicki) wrote:

> In other words: are
> standard library implementors allowed to actually free memory (and lower
> capacity) of vector in standard conforming implementation of
> vector<T>::erase and vector<T>::clear ? If no, why ?

They may iff reserve has not been called.  Do you want a
reserve_has_been called member of std::vector?

John

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Brok@rubikon.pl ("Bronek Kozicki") wrote in message
news:<e6e7e$3f98ef32$3e6fced2$30189@nf1.news-service.com>...

> C++ standard does not mention what happens with memory allocated
> inside vector when whole vector is being invalidated by following
> operation (clause 23.2.4.3/3) :

> v.erase(v.begin(), v.end());

Implementation defined.

> >From definition of function "reserve" (clause 23.2.4.2/2) it's
> assumed that erase will not free memory allocated by vector.  But it's
> not stated explicitly in standard, thus this assumption is doubtful -
> especially when whole vector is being erased.  Is it omission in
> standard or it's left unspecified on purpose (eg. to allow space
> optimization, but not require it) ?

The standard pretty explicitly guarantees that the following code will
work:

    std::vector< int > v ;
    v.reserve( 100 ) ;
    v.erase( v.begin(), v.end() ) ;
    v.push_back( 1 ) ;
    int& ri = v[ 0 ] ;
    v.push_back( 2 ) ;
    ri = 100 ;

The standard doesn't ever speak in terms of when memory will be freed,
etc.  It gives required semantics.  If you can find a way to make the
above work, and also free memory in erase, then it is legal to do so.

--
James Kanze           GABI Software        mailto:kanze@gabi-soft.fr
Conseils en informatique orient   e objet/     http://www.gabi-soft.fr
                    Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]