473,324 Members | 2,196 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,324 software developers and data experts.

resize and clear of vector

Hi,
I am using a vector to reserve certain amount of memory, and reuse
it for new set of data, to avoid reallocation of memory.
so the call is something like
vector<my_datav;///the temporary storage.
v.reserve(300); ///at max I have 300 data.

now, my_data doesn't have a default ctor (as it doesn't have a default
state).

to use vector v again and again,
I am doing ,
v.resize(0);
////and then use it. I can do v.clear() for better.
Now the questions are,
1) do clear zero's capacity , i.e frees memory? (Then I can't use it,
as it iteration the vector will reallocate memory)
2) do resize to a size smaller than existing size reduces capacity
(Then resize(0) will also do the same thing )
3) do a resize with a size smaller than existing size requires
default (or any other ctor ) ?

thanks

Mar 21 '07 #1
17 11843
toton wrote:
1) do clear zero's capacity , i.e frees memory?
No. std::vector never frees memory (except when it's destroyed,
of course).
2) do resize to a size smaller than existing size reduces capacity
No.

If you want to free the memory taken by a std::vector, there's
a known trick for that:

{
std::vector<my_datatmp;
v.swap(tmp);
}
// Here 'v' will have 0 size and will have no memory allocated

Note that the curly brackets are very relevant there.
Mar 21 '07 #2
toton a écrit :
Hi,
I am using a vector to reserve certain amount of memory, and reuse
it for new set of data, to avoid reallocation of memory.
so the call is something like
vector<my_datav;///the temporary storage.
v.reserve(300); ///at max I have 300 data.

now, my_data doesn't have a default ctor (as it doesn't have a default
state).

to use vector v again and again,
I am doing ,
v.resize(0);
////and then use it. I can do v.clear() for better.
Now the questions are,
1) do clear zero's capacity , i.e frees memory? (Then I can't use it,
as it iteration the vector will reallocate memory)
It is not required by the standard thus AFAIK existing implementations
don't.
2) do resize to a size smaller than existing size reduces capacity
(Then resize(0) will also do the same thing )
It is not required by the standard thus AFAIK existing implementations
don't.
3) do a resize with a size smaller than existing size requires
default (or any other ctor ) ?
No reason it should.

The usual trick to release memory of a vector is:
vector<myClassmy_vector(100000);

//clear by swapping with empty vector
std::vector<myClass>().swap(my_vector);
Michael
Mar 21 '07 #3
toton a écrit :
Hi,
I am using a vector to reserve certain amount of memory, and reuse
it for new set of data, to avoid reallocation of memory.
so the call is something like
vector<my_datav;///the temporary storage.
v.reserve(300); ///at max I have 300 data.

now, my_data doesn't have a default ctor (as it doesn't have a default
state).
[snip]
3) do a resize with a size smaller than existing size requires
default (or any other ctor ) ?
I don't understand your concern about default constructor.

std::vector doesn't require a default constructor. You can pass the
object to use for construction as second parameter.

vector<my_datav(10,my_data(42);

The same is true of resize:
v.resize(72,my_data(36);

Michael
Mar 21 '07 #4
On Mar 21, 1:12 pm, Juha Nieminen <nos...@thanks.invalidwrote:
toton wrote:
1) do clear zero's capacity , i.e frees memory?

No. std::vector never frees memory (except when it's destroyed,
of course).
2) do resize to a size smaller than existing size reduces capacity

No.

If you want to free the memory taken by a std::vector, there's
a known trick for that:

{
std::vector<my_datatmp;
v.swap(tmp);
}
// Here 'v' will have 0 size and will have no memory allocated

Note that the curly brackets are very relevant there.
Thanks,
The trick works.
But, as I am not interested to release memory (except destructor of
course ) , as your post says clear doesn't release memory.
However , from this code it gives output ,
vector<intvi(10) ;
cout<<"sz "<<vi.size()<<" cap "<<vi.capacity()<<endl; (size &
capacity 10, as expected)
std::generate(vi.begin(),vi.end(),rand);
cout<<endl; for_each(vi.begin(),vi.end(),cout<<_1<<" ");
cout<<"sz "<<vi.size()<<" cap "<<vi.capacity()<<endl; (size &
capacity 10, as expected)
vi.clear();
cout<<"sz "<<vi.size()<<" cap "<<vi.capacity()<<endl; (size &
capacity 0, I expected size = 0 while capacity 10)
However the statement vi.resize(0); makes size 0 , capacity 10.
so, as I don't want to release memory except destructor ,
1) which never releases memory resize(0) or clear() ?
2) the capacity is giving a wrong result ?
3) result of clear (and/or) resize whether to release memory is
implementation dependent ?
I am using Visual Studio 7.1 with MS implementation of std lib.

thanks
abir


Mar 21 '07 #5
Michael DOUBEZ wrote:
>to use vector v again and again,
I am doing ,
v.resize(0);
////and then use it. I can do v.clear() for better.
Now the questions are,
1) do clear zero's capacity , i.e frees memory? (Then I can't use it,
as it iteration the vector will reallocate memory)
It is not required by the standard thus AFAIK existing implementations
don't.
Actually, the standard requires that this is not done.
> 2) do resize to a size smaller than existing size reduces capacity
(Then resize(0) will also do the same thing )
It is not required by the standard thus AFAIK existing implementations
don't.
Actually, the standard requires that this is not done.

Mar 21 '07 #6
On Mar 21, 2:33 pm, Rolf Magnus <ramag...@t-online.dewrote:
Michael DOUBEZ wrote:
to use vector v again and again,
I am doing ,
v.resize(0);
////and then use it. I can do v.clear() for better.
Now the questions are,
1) do clear zero's capacity , i.e frees memory? (Then I can't use it,
as it iteration the vector will reallocate memory)
It is not required by the standard thus AFAIK existing implementations
don't.

Actually, the standard requires that this is not done.
2) do resize to a size smaller than existing size reduces capacity
(Then resize(0) will also do the same thing )
It is not required by the standard thus AFAIK existing implementations
don't.

Actually, the standard requires that this is not done.
When I go through the MS implementation (VS 7.1 ) of STL, clear looks
like,
void clear()
{ // erase all
_Tidy();
}
void _Tidy()
{ // free all storage
if (_Myfirst != 0)
{ // something to free, destroy and deallocate it
_Destroy(_Myfirst, _Mylast);
this->_Alval.deallocate(_Myfirst, _Myend - _Myfirst);///check this
line. it deallocates
}
_Myfirst = 0, _Mylast = 0, _Myend = 0;
}
Thus it removes memory (deallocates) not only destroys. That is why
capacity comes as 0 after clear. However it is not same for resize(0),
where it doesn't call deallocate (only construct or destroy) .
The results are given in my previous post.
Is it wrong according to std ? or just implementation defined ?
Thus which of the two (clear / resize(0) ) NEVER releases memory
according to std , if any one of them do at all.

thanks
abir

Mar 21 '07 #7
toton wrote:
On Mar 21, 2:33 pm, Rolf Magnus <ramag...@t-online.dewrote:
>Michael DOUBEZ wrote:
>to use vector v again and again,
I am doing ,
v.resize(0);
////and then use it. I can do v.clear() for better.
Now the questions are,
1) do clear zero's capacity , i.e frees memory? (Then I can't use it,
as it iteration the vector will reallocate memory)
It is not required by the standard thus AFAIK existing implementations
don't.

Actually, the standard requires that this is not done.
> 2) do resize to a size smaller than existing size reduces capacity
(Then resize(0) will also do the same thing )
It is not required by the standard thus AFAIK existing implementations
don't.

Actually, the standard requires that this is not done.

When I go through the MS implementation (VS 7.1 ) of STL, clear looks
like,
void clear()
{// erase all
_Tidy();
}
void _Tidy()
{// free all storage
if (_Myfirst != 0)
{ // something to free, destroy and deallocate it
_Destroy(_Myfirst, _Mylast);
this->_Alval.deallocate(_Myfirst, _Myend - _Myfirst);///check this
line. it deallocates
}
_Myfirst = 0, _Mylast = 0, _Myend = 0;
}
Seems to be a violation of the C++ standard.
Thus it removes memory (deallocates) not only destroys. That is why
capacity comes as 0 after clear. However it is not same for resize(0),
where it doesn't call deallocate (only construct or destroy) .
The results are given in my previous post.
Is it wrong according to std ? or just implementation defined ?
The C++ standard says that for any sequence a, a.clear() should do the
equivalent to a.erase(a.begin(), a.end()). The description of the effects
of std::vector::erase doesn't mention any change in capacity/reallocation.
Thus which of the two (clear / resize(0) ) NEVER releases memory
according to std , if any one of them do at all.
The standard says that the behavior of resize() if the new size is less than
the old one is equivalent to the corresponding erase() call. Since that's
also the case for clear(), both must have exactly the same result in a
conforming implementation.

Mar 21 '07 #8
Rolf Magnus a écrit :
Michael DOUBEZ wrote:
>>to use vector v again and again,
I am doing ,
v.resize(0);
////and then use it. I can do v.clear() for better.
Now the questions are,
1) do clear zero's capacity , i.e frees memory? (Then I can't use it,
as it iteration the vector will reallocate memory)
It is not required by the standard thus AFAIK existing implementations
don't.

Actually, the standard requires that this is not done.
>> 2) do resize to a size smaller than existing size reduces capacity
(Then resize(0) will also do the same thing )
It is not required by the standard thus AFAIK existing implementations
don't.

Actually, the standard requires that this is not done.
I could not find the relevant requirement in the standard.
Can you or anyone provide it ?

Michael
Mar 21 '07 #9
>Actually, the standard requires that this is not done.

Where? The standard is silent on this. The standard is inadeqate.
Seems to be a violation of the C++ standard.
No. The standard neither forbids nor blesses the practice.
Therefore it is implementation defined.
The standard says that the behavior of resize() if the new size is less
than
the old one is equivalent to the corresponding erase() call. Since that's
also the case for clear(), both must have exactly the same result in a
conforming implementation.
Yes. Which does not say anything about what happens to the memory.

Stephen Howe

Mar 21 '07 #10
>Actually, the standard requires that this is not done.
>
I could not find the relevant requirement in the standard.
Can you or anyone provide it ?
He is incorrect. It is not there.
The standard is _silent_ on what happens to memory and that means it is
implementation defined.

Stephen Howe
Mar 21 '07 #11
"Stephen Howe" <sjhoweATdialDOTpipexDOTcomwrote:
>>Actually, the standard requires that this is not done.

Where? The standard is silent on this. The standard is inadeqate.
It gives information about the effects that erase() has, and re-allocation
is not one of those, so it doesn't happen. Invalidation of iterators to the
erased elements and those after it is an effect, but invalidation of those
before is not. A re-allocation would invalidate all iterators, so it can't
happen.
What makes you believe it's optional?
>The standard says that the behavior of resize() if the new size is less
than the old one is equivalent to the corresponding erase() call. Since
that's also the case for clear(), both must have exactly the same result
in a conforming implementation.

Yes. Which does not say anything about what happens to the memory.
It says that the implementation the OP is using is non-conforming, because
the behavor of resize(0) is different from that of clear().

Mar 21 '07 #12
"Rolf Magnus" <ra******@t-online.dewrote in message
news:et************@news.t-online.com...
"Stephen Howe" <sjhoweATdialDOTpipexDOTcomwrote:
>>>Actually, the standard requires that this is not done.

Where? The standard is silent on this. The standard is inadeqate.

It gives information about the effects that erase() has, and re-allocation
is not one of those, so it doesn't happen. Invalidation of iterators to
the
erased elements and those after it is an effect, but invalidation of those
before is not. A re-allocation would invalidate all iterators, so it can't
happen.
What makes you believe it's optional?
>>The standard says that the behavior of resize() if the new size is less
than the old one is equivalent to the corresponding erase() call. Since
that's also the case for clear(), both must have exactly the same result
in a conforming implementation.

Yes. Which does not say anything about what happens to the memory.

It says that the implementation the OP is using is non-conforming, because
the behavor of resize(0) is different from that of clear().
Actually, it says nothing of the sort. But there was a Defect Report
asking for clarification, and the Library Working Group chose to
clarify the matter by ruling that the library can't reduce the
capacity on a clear. That ruling came down after VC++ V7.1 froze,
but you'll find the now "correct" behavior in VC++ V8.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Mar 21 '07 #13
P.J. Plauger wrote:
>>>The standard says that the behavior of resize() if the new size is less
than the old one is equivalent to the corresponding erase() call. Since
that's also the case for clear(), both must have exactly the same
result in a conforming implementation.

Yes. Which does not say anything about what happens to the memory.

It says that the implementation the OP is using is non-conforming,
because the behavor of resize(0) is different from that of clear().

Actually, it says nothing of the sort.
Table 67 says that the effect of clear() for sequences is the same as
erase(begin(), end()), and 23.2.4.2 says that resize(sz) has the same
effect as:

if (sz size())
insert(end(), sz-size(), c);
else if (sz < size())
erase(begin()+sz, end());
else
; // do nothing
so doesn't that mean that clear() has the same effect as resize(0)?

Mar 21 '07 #14
"Rolf Magnus" <ra******@t-online.dewrote in message
news:et*************@news.t-online.com...
P.J. Plauger wrote:
>>>>The standard says that the behavior of resize() if the new size is
less
than the old one is equivalent to the corresponding erase() call.
Since
that's also the case for clear(), both must have exactly the same
result in a conforming implementation.

Yes. Which does not say anything about what happens to the memory.

It says that the implementation the OP is using is non-conforming,
because the behavor of resize(0) is different from that of clear().

Actually, it says nothing of the sort.

Table 67 says that the effect of clear() for sequences is the same as
erase(begin(), end()), and 23.2.4.2 says that resize(sz) has the same
effect as:

if (sz size())
insert(end(), sz-size(), c);
else if (sz < size())
erase(begin()+sz, end());
else
; // do nothing
so doesn't that mean that clear() has the same effect as resize(0)?
The issue in question was whether, under any circumstances, vector
could reduce capacity. The C++ Standard just didn't say. The LWG,
after some discussion, determined that clear should not reduce
capacity (even though it doesn't explicitly say that it can't) but
swap should (even though it doesn't explicitly say that it can).
IOW, the current rule is an *interpretation* of what should be
desired behavior.

Many years ago, I had several requests from customers for some way
to reduce the capacity of a vector. Absent clear guidance from the
C++ Standard, I picked a way and those customers were happy. When
the LWG made a different rule, the Dinkumware library changed to
match the new rule. You can persist all you want in asserting that
the answer is obvious in hindsight, but we did have to guess.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Mar 21 '07 #15
P.J. Plauger wrote:
"Rolf Magnus" <ra******@t-online.dewrote in message
news:et*************@news.t-online.com...
>P.J. Plauger wrote:
>>>>>The standard says that the behavior of resize() if the new size is
>less than the old one is equivalent to the corresponding erase()call.
>Since that's also the case for clear(), both must have exactly the
>same result in a conforming implementation.
>
Yes. Which does not say anything about what happens to the memory.

It says that the implementation the OP is using is non-conforming,
because the behavor of resize(0) is different from that of clear().

Actually, it says nothing of the sort.

Table 67 says that the effect of clear() for sequences is the same as
erase(begin(), end()), and 23.2.4.2 says that resize(sz) has the same
effect as:

if (sz size())
insert(end(), sz-size(), c);
else if (sz < size())
erase(begin()+sz, end());
else
; // do nothing
so doesn't that mean that clear() has the same effect as resize(0)?

The issue in question was whether, under any circumstances, vector
could reduce capacity.
We had two issues here. The second one is if resize(0) may behave
differently than clear(), and C++98 explicitly says that this is not
allowed.
The C++ Standard just didn't say.
I was assuming that it's enough that a reallocation is not mentioned as an
effect of erase(). It could have been more explicit though.
The LWG, after some discussion, determined that clear should not reduce
capacity (even though it doesn't explicitly say that it can't) but swap
should (even though it doesn't explicitly say that it can).
The 98 version of the standard (the only one available to me ATM) forbids
that. Was it changed in the 03 version?
IOW, the current rule is an *interpretation* of what should be desired
behavior.
I really hate it if a standard must be interpreted.

Mar 23 '07 #16
Rolf Magnus wrote:
:: P.J. Plauger wrote:
::
::: "Rolf Magnus" <ra******@t-online.dewrote in message
::: news:et*************@news.t-online.com...
:::
:::
::: The issue in question was whether, under any circumstances, vector
::: could reduce capacity.
::
:: We had two issues here. The second one is if resize(0) may behave
:: differently than clear(), and C++98 explicitly says that this is not
:: allowed.
::
::: The C++ Standard just didn't say.
::
:: I was assuming that it's enough that a reallocation is not mentioned
:: as an effect of erase(). It could have been more explicit though.
::
::: The LWG, after some discussion, determined that clear should not
::: reduce capacity (even though it doesn't explicitly say that it
::: can't) but swap should (even though it doesn't explicitly say that
::: it can).
::
:: The 98 version of the standard (the only one available to me ATM)
:: forbids that. Was it changed in the 03 version?
::
::: IOW, the current rule is an *interpretation* of what should be
::: desired behavior.
::
:: I really hate it if a standard must be interpreted.

It is not really an interpretation, but a clarification. :-)

From what I understand, the original question was about the standard saying
that after a call to reserve(x), the capacity can never go below x. But what
if reserve() is never called, can the capacity shrink then?

And the clarification is: No!
The only sort-of-exception is swap, which sort of reduces the capacity, but
can also be seen as only transferring it elsewhere.

Bo Persson
Mar 24 '07 #17
Bo Persson wrote:
Rolf Magnus wrote:
:: P.J. Plauger wrote:
::
::: "Rolf Magnus" <ra******@t-online.dewrote in message
::: news:et*************@news.t-online.com...
:::
:::
::: The issue in question was whether, under any circumstances, vector
::: could reduce capacity.
::
:: We had two issues here. The second one is if resize(0) may behave
:: differently than clear(), and C++98 explicitly says that this is not
:: allowed.
::
::: The C++ Standard just didn't say.
::
:: I was assuming that it's enough that a reallocation is not mentioned
:: as an effect of erase(). It could have been more explicit though.
::
::: The LWG, after some discussion, determined that clear should not
::: reduce capacity (even though it doesn't explicitly say that it
::: can't) but swap should (even though it doesn't explicitly say that
::: it can).
::
:: The 98 version of the standard (the only one available to me ATM)
:: forbids that. Was it changed in the 03 version?
::
::: IOW, the current rule is an *interpretation* of what should be
::: desired behavior.
::
:: I really hate it if a standard must be interpreted.

It is not really an interpretation, but a clarification. :-)
Well, if there are different views, it's an interpretation.
From what I understand, the original question was about the standard
saying that after a call to reserve(x), the capacity can never go below x.
But what if reserve() is never called, can the capacity shrink then?

And the clarification is: No!
My impression was that swap() was guaranteed to reduce the capacity and
everything else was guaranteed not to. I thought that was absolutely clear,
considering that I read something like that quite often here and elsewhere.
I'm not so sure now, since there seem to be different opinions, and the
standard is not really fully clear about it.
The only sort-of-exception is swap, which sort of reduces the capacity,
but can also be seen as only transferring it elsewhere.
Actually, I didn't find anything in the standard that says so, but maybe I
just missed it. Could you give chapter/verse?

Mar 24 '07 #18

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Sean Dettrick | last post by:
Hi, Can anyone please tell me if the following is possible, and if so, what is the correct syntax? I'd like to resize a vector (and access other vector member functions) via a pointer to that...
9
by: fudmore | last post by:
Hello Everybody. I have a Segmentation fault problem. The code section at the bottom keeps throwing a Segmentation fault when it enters the IF block for the second time. const int...
1
by: Michael Jasn | last post by:
I had a question about memory management. Please look at the two functions below. Can you answer the two questions in the comments below. Thanks so much. -Mike func1(std::vector<Point>&...
8
by: Alex Vinokur | last post by:
What is relation between std::vector's reserve() and erase()/clear()? vector<int> v; v.reserve(100); v.resize(100); v.erase(v.end()); How many elements are reserved here: 100 or 99?
9
by: Timothee Groleau | last post by:
Hi all, My name is Tim, I'm just getting started with C++ and this is my first post to the group. Is there a standard recommended approach to use a vector of pointers along with <algorithm>?...
14
by: Tarun | last post by:
Hello, I am facing problem sometimes while I am trying to do push_back on a vector. Currently I am doing resize of the vector increasing the size by one and then push_back and seems like the...
5
by: cbbibleboy | last post by:
Hey, I've been getting some very strange results with what seems to be very simple code. All I'm doing is trying to use an STL vector of "cSprite"s -- a class I wrote. The problem arises when I try...
2
by: nikiplos | last post by:
Hi, all... I have a problem when trying to reallocate a vector for a second time inside a loop. The order is somelike: for (n=k; n<L; n++) { vector.resize(n, (long) 0); ... ...
2
by: Kazzie | last post by:
I have a structure struct Rulestrc { char* rulen; vector<char*>v6; char* resp; }; I then create an array of structures - Rulestrc tp. However the content of tp is constantly changing...
3
by: deepak1905 | last post by:
Hi, I am working on c++ in a linux system ( Fedora core 4 ), kernel version - 2.6.11-1.1369_FC4 gcc version - 4.0.0 20050519 ( Red Hat 4.0.0-8 ) In my code i am creating a vector to store...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.