By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,318 Members | 2,116 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,318 IT Pros & Developers. It's quick & easy.

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

P: n/a
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.
Jul 22 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
* 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.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 22 '05 #2

P: n/a
Alf P. Steinbach wrote:
* 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);

Jul 22 '05 #3

P: n/a
In article <cg*************@news.t-online.com>,
Rolf Magnus <ra******@t-online.de> wrote:
Alf P. Steinbach wrote:
* 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);


That should work. This might be more efficient:

original.reserve();

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

-Howard
Jul 22 '05 #4

P: n/a
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.

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

Jul 22 '05 #5

P: n/a
"CoolPint" <co******@yahoo.co.uk> wrote in message
news:15**************************@posting.google.c om...
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".

--
David Hilsee
Jul 22 '05 #6

P: n/a
* Rolf Magnus:
Alf P. Steinbach wrote:
* 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.


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

Otherwise "assignment" by itself would be enough.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 22 '05 #7

P: n/a
Alf P. Steinbach wrote:
* Rolf Magnus:
Alf P. Steinbach wrote:
> * 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.


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.

Jul 22 '05 #8

P: n/a
* Rolf Magnus:
Alf P. Steinbach wrote:
* Rolf Magnus:
Alf P. Steinbach wrote:

> * 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.


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.


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.

Otherwise "assignment" by itself would be enough.


I don't understand what you mean by that.


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

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 22 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.