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

Discussion in 'C++' started by CoolPint, Aug 28, 2004.

  1. CoolPint

    CoolPint Guest

    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.
    CoolPint, Aug 28, 2004
    #1
    1. Advertising

  2. * 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?
    Alf P. Steinbach, Aug 28, 2004
    #2
    1. Advertising

  3. CoolPint

    Rolf Magnus Guest

    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);
    Rolf Magnus, Aug 28, 2004
    #3
  4. In article <cgppi1$tug$02$-online.com>,
    Rolf Magnus <> 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
    Howard Hinnant, Aug 28, 2004
    #4
  5. CoolPint

    CoolPint Guest

    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
    CoolPint, Aug 29, 2004
    #5
  6. CoolPint

    David Hilsee Guest

    "CoolPint" <> wrote in message
    news:...
    > 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
    David Hilsee, Aug 29, 2004
    #6
  7. * 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?
    Alf P. Steinbach, Aug 29, 2004
    #7
  8. CoolPint

    Rolf Magnus Guest

    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.
    Rolf Magnus, Aug 30, 2004
    #8
  9. * 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?
    Alf P. Steinbach, Aug 30, 2004
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Raja
    Replies:
    12
    Views:
    24,332
    John Harrison
    Jun 21, 2004
  2. Peter Jansson
    Replies:
    5
    Views:
    6,255
    Ivan Vecerina
    Mar 17, 2005
  3. Jeffrey Walton
    Replies:
    10
    Views:
    925
    Mathias Gaunard
    Nov 26, 2006
  4. Christopher Pisz
    Replies:
    11
    Views:
    526
    James Kanze
    Jan 13, 2008
  5. Casey Hawthorne
    Replies:
    1
    Views:
    689
    Arne Vajhøj
    Mar 18, 2009
Loading...

Share This Page