How can I "reduce" the size of internal buffer used by std::string?

[CoolPint]

Is there any way I can reduce the size of internal buffer to store
characters by std::string?

After having used a string object to store large strings, the object
seems to
retain the large buffer as I found out calling by capacity().

What if I do not need all that buffer space again want to reduce the
size to
a smaller one? I tried resize() passing a smaller size than the
current one,
but its capacity() still reports the old big size.

Here is a very contrived situation:

std::string msg;
msg.resize(10000);
// do whatever with the large buffer
msg.resize(80);
// I don't want the large buffer anymore
msg.capacity();
// but still the buffer seems to hold large space.

Or am I trying to do something I should not?

If there is a way to do this, I would love to learn about it.
If I am not "supposed" to do this, then I would like to know the
reasons behind.

Thank you in advance for your help and time.

 

[Alf P. Steinbach]

* CoolPint:

...

The idiom for std::vector is to swap the vector with an empty
vector which is then destroyed.

I haven't checked whether std::string is swappable but presumably
it is.

The only problem is then to keep the logical contents, and that you
can do by (copy) assignment before swapping.

 

[Rolf Magnus]

* CoolPint:

The idiom for std::vector is to swap the vector with an empty
vector which is then destroyed.

I haven't checked whether std::string is swappable but presumably
it is.

The only problem is then to keep the logical contents, and that you
can do by (copy) assignment before swapping.

Would that be actually guaranteed to do The Right Thing? I'm thinking
here about reference counted strings that share their string data.
Copying would then mean that the copy will just use the same memory as
the original. Maybe copying using iterators would be better, like:

std::string tmp(original.begin(), original.end());
std::swap(tmp, original);

 

[Howard Hinnant]

Would that be actually guaranteed to do The Right Thing? I'm thinking
here about reference counted strings that share their string data.
Copying would then mean that the copy will just use the same memory as
the original. Maybe copying using iterators would be better, like:

std::string tmp(original.begin(), original.end());
std::swap(tmp, original);

That should work. This might be more efficient:

original.reserve();

For string, reserve() is a non-binding request to shrink to fit.

-Howard

 

[CoolPint]

Thank you for taking time to answer my question.
The exact problem is "non-binding" nature of reserve(), and cannot be
certain it would actually reduce the buffer size. In fact a few test
with g++ seems to suggest reserve seems to ignore the request when the
new size is less than current capacity()

The swapping method sounds good except that it would require the
creation of another "temporary space".

So am I correct in thinking there is no direct and sure way of
reducing the internal buffer size?

I guess that's how the class is supposed to work and I should resort
to managing my own buffer based on C-style string manipulation if I
want fine control over the buffer size.

Thank you again.

 

[David Hilsee]

Thank you for taking time to answer my question.
The exact problem is "non-binding" nature of reserve(), and cannot be
certain it would actually reduce the buffer size. In fact a few test
with g++ seems to suggest reserve seems to ignore the request when the
new size is less than current capacity()

The swapping method sounds good except that it would require the
creation of another "temporary space".

So am I correct in thinking there is no direct and sure way of
reducing the internal buffer size?

I guess that's how the class is supposed to work and I should resort
to managing my own buffer based on C-style string manipulation if I
want fine control over the buffer size.

If you want fine control over the buffer size, why don't you call reserve()
before you increase the length of the string? If you do not know the needed
capacity ahead of time, then I don't see how your own C-style string
manipulation is going to help you avoid creating another "temporary space".

 

[Alf P. Steinbach]

* Rolf Magnus:

Would that be actually guaranteed to do The Right Thing? I'm thinking
here about reference counted strings that share their string data.
Copying would then mean that the copy will just use the same memory as
the original.

When I wrote "copy" in addition to "assignment" I meant, uh, "copy".

Otherwise "assignment" by itself would be enough.

 

[Rolf Magnus]

* Rolf Magnus:

When I wrote "copy" in addition to "assignment" I meant, uh, "copy".

Well, "copy assignment" is what operator= does. The question was just
whether it makes a deep copy or a shallow one. And I think it can make
either one, depending on the implementaiton.

Otherwise "assignment" by itself would be enough.

I don't understand what you mean by that.

 

[Alf P. Steinbach]

* Rolf Magnus:

Well, "copy assignment" is what operator= does. The question was just
whether it makes a deep copy or a shallow one. And I think it can make
either one, depending on the implementaiton.

The term "copy assignment" is used in the Holy Standard to distinguish
copying by way of assignment as opposed to copying by way of construction.

So you thought I was pointing out that the assignment operator should be
used as opposed to the copy constructor.

But there is no difference so that this meaning could be relevant: in
choosing an interpretation, simply check first whether it's meaningful.

I don't understand what you mean by that.

Unqualified "assignment" by itself means using the assignment operator.