basic_string - once more...

Stefan Olsson stefan@noname4us.com
Sun Nov 11 08:54:00 GMT 2001


Hi!

The issue that i refer to was discussed in detail starting (I think...)
with http://gcc.gnu.org/ml/libstdc++/2001-07/msg00004.html

I am well aware that one should use reserve() as the main tool to avoid
this problem, but when for instance inserting into a map<string,string> one
would still end up with strings that have capacity == length in the current
implementation, greatly increasing memory fragmentation (at least in our
specfic application which builds strings based on data from a SQL
database).

The worst case (not real life, but anyway) example would be:
#include <string>

using namespace std;

int main()
{
        string s;
        int i;

        for( i=0; i<1000000; i++ )
        {
                s+="a";
        }
}

This code will effectively generate "i" number of malloc calls with the
current STL and what I am looking for is a way of getting the STL to
allocate in X sized chunks (where X would be configurable and in our case
probably 8 or 16 bytes) as the GCC 2.95 did.

Thanks!

/Stefan

Paolo Carlini wrote:

> Stefan Olsson wrote:
>
> > If it was posted to the list, please give me some pointer to it
> > because i can't find anything else than the reserve() bug discussion
> > and this is a allocation issue.
> >
> > Thanks!
> >
> > /Stefan
>
> Hi Stefan, it's Paolo here, in fact I'm not sure either that the bug I
> have just fixed has really to do with your own problem.
>
> I would be happy to work with you toward a solution of your problem but,
> *please* summarize it here once more, with a concise description and a
> couple of testcases (I must add that if it is in fact an eminently
> memory allocation problem Loren Rittle in probably the best person to
> take care of it).
>
> Cheers,
> Paolo.

--
Military intelligence is a contradiction in terms.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20011111/59403747/attachment.htm>


More information about the Libstdc++ mailing list