basic_string - once more...

[Paolo Carlini]

Stefan Olsson wrote:

> 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";
>         }
> }

Ok. Thanks. Now I'm beginning to understand in detail your problem. Most definitely it is
*not* something dealt with by my recent patch :-(

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

Of course you will agree that, since libstdc++-v3 aims at a full compliance with the ISO
standard, we cannot simply add methods here and there to the string class. Ok. What you
are proposing can only be an *implementation* strategy, tuned, once and for all at
*configure*-time in my undertanding. Ok?

Even if libstdc++-v2 was a GCC software indeed ;-), I believe now that the youngest among
us would benefit from a detailed description of it behaviour (as far as strings are
concerned, of course), in order to work toward keeping the best of it in the libstdc++-v3.
This is what you want, right?

Could you please begin to take care of this part of the project? Moreover, what values for
the *X* above do you think are the most reasonable?

Cheers,
Paolo.