«

Hi

Vectors allocate a bit more storage than is needed to avoid repeated
reallocations. Is there a way to force the vector to release the extra
storage and keep only what is strictly necessary?

Thanks in advance for your time.

jacob

jacob navia <> writes:
> Vectors allocate a bit more storage than is needed to avoid repeated
> reallocations. Is there a way to force the vector to release the extra
> storage and keep only what is strictly necessary?

In C++11, there's the "shrink_to_fit" method...

http://en.cppreference.com/w/cpp/con.../shrink_to_fit

-miles

--
"Most attacks seem to take place at night, during a rainstorm, uphill,
where four map sheets join." -- Anon. British Officer in WW I

Le 30/04/12 22:02, Miles Bader a écrit :
>
> In C++11, there's the "shrink_to_fit" method...
>
> http://en.cppreference.com/w/cpp/con.../shrink_to_fit
>
> -miles
>
Thanks a lot!

jacob

On Mon, 30 Apr 2012 21:55:28 +0200, jacob navia wrote:

> Vectors allocate a bit more storage than is needed to avoid repeated
> reallocations. Is there a way to force the vector to release the extra
> storage and keep only what is strictly necessary?

No. Miles mentioned C++11's shrink_to_fit() method, but that's only a
request; it can legitimately be ignored.

Le 01/05/12 06:31, Nobody a écrit :
> On Mon, 30 Apr 2012 21:55:28 +0200, jacob navia wrote:
>
>> Vectors allocate a bit more storage than is needed to avoid repeated
>> reallocations. Is there a way to force the vector to release the extra
>> storage and keep only what is strictly necessary?
>
> No. Miles mentioned C++11's shrink_to_fit() method, but that's only a
> request; it can legitimately be ignored.
>
Ahhh it is only a *request* ???

It looked official enough for me!

Thanks for this clarification. I thought it was in the standard already.

On 30.04.12 21.55, jacob navia wrote:
> Vectors allocate a bit more storage than is needed to avoid repeated
> reallocations. Is there a way to force the vector to release the extra
> storage and keep only what is strictly necessary?

This requires a reallocation in general.
Simply create a new vector with the appropriate size and use this one.

vector<int> current;

if (current.size() != current.capacity())
{ vector<int> newvec;
newvec.reserve(current.size);
newvec.assign(current.begin(), current.end());
current.swap(newvec);
}

There is no guarantee that reserve does exactly what you intend, but
calling it on an empty vector usually does what you want. You could
check newvec.capacity() to validate that. But keep in mind, that
allocating a bit more than required could be for free on a certain
platform because the physical allocation size is restricted to multiples
of some value. So I would not care about small differences.


Marcel

On Tue, 01 May 2012 08:46:11 +0200, jacob navia wrote:

>> No. Miles mentioned C++11's shrink_to_fit() method, but that's only a
>> request; it can legitimately be ignored.
>>
> Ahhh it is only a *request* ???
>
> It looked official enough for me!
>
> Thanks for this clarification. I thought it was in the standard already.

It is in the standard, but the standard only requires that the method
exists, it doesn't require that it actually minimises the memory used (or
even what that means).

I can't think of any language which treats memory consumption as a
functional requirement.

In C++, vector::reserve() and vector::capacity() were never strictly about
memory consumption per se, but rather about the fact that iterators are
invalidated by reallocation; if v.capacity()-v.size()==N, you can append
up to N elements to the vector without invalidating any iterators on it.

jacob navia <> writes:
>>> Vectors allocate a bit more storage than is needed to avoid repeated
>>> reallocations. Is there a way to force the vector to release the extra
>>> storage and keep only what is strictly necessary?
>>
>> No. Miles mentioned C++11's shrink_to_fit() method, but that's only a
>> request; it can legitimately be ignored.
>>
> Ahhh it is only a *request* ???
>
> It looked official enough for me!
> Thanks for this clarification. I thought it was in the standard already.

It is in the standard.

However, like _anything_ in the standard, it's subject to "quality of
implementation": good vendors will make it do what you expect -- this
method is easy to implement in most cases, so there's little reason
not to -- but a crappy vendor may implement it crappily.

[but the same caveat applies to almost everything -- for all you know,
your vendor allocates 1MB for every new vector ... nothing in the
standard forbids it...]

-miles

--
We have met the enemy, and he is us. -- Pogo

Le 01/05/12 10:23, Marcel Müller a écrit :
>
> There is no guarantee that reserve does exactly what you intend, but
> calling it on an empty vector usually does what you want. You could
> check newvec.capacity() to validate that. But keep in mind, that
> allocating a bit more than required could be for free on a certain
> platform because the physical allocation size is restricted to multiples
> of some value. So I would not care about small differences.

Well, the context is that I am writing a containers library for the C
language. In C, memory management and keeping software small are
important considerations, to the contrary of C++.

I thought that

Vector *vector;
extern iVectorInterface iVector; // The interface table

iVector.Resize(vector,iVector.GetSize(vector));

would be an "idiom" within my library to request the library to shed
any extra storage used. This would arrive when you know that the
vector will never be modified again, for instance.

Simply requesting a resize with the exact number of elements currently
stored would mean that the vector should be shrunk to fit.

I thought that a new method would simply be too heavy.

Within that context, I wanted to add an example of how this is done in
C++, hence my question.

Thanks for your answer.

jacob

On 05/ 2/12 08:46 PM, jacob navia wrote:
> Le 01/05/12 10:23, Marcel Müller a écrit :
>>
>> There is no guarantee that reserve does exactly what you intend, but
>> calling it on an empty vector usually does what you want. You could
>> check newvec.capacity() to validate that. But keep in mind, that
>> allocating a bit more than required could be for free on a certain
>> platform because the physical allocation size is restricted to multiples
>> of some value. So I would not care about small differences.
>
> Well, the context is that I am writing a containers library for the C
> language. In C, memory management and keeping software small are
> important considerations, to the contrary of C++.

Where do you get that idea from?

If the underlying memory subsystem allocates in multiples of say 32
bytes and your vector uses 33, how can you give back the remaining 31?

> I thought that
>
> Vector *vector;
> extern iVectorInterface iVector; // The interface table
>
> iVector.Resize(vector,iVector.GetSize(vector));
>
> would be an "idiom" within my library to request the library to shed
> any extra storage used. This would arrive when you know that the
> vector will never be modified again, for instance.

So would it be non-binding like shrink_to_fit, or would the
implementation be obliged to somehow give back those 31 bytes?

> Simply requesting a resize with the exact number of elements currently
> stored would mean that the vector should be shrunk to fit.

Which is what shrink_to_fit is intended to do - with the sensible note:

"The request is non-binding to allow latitude for implementation
specific optimizations"

--
Ian Collins