[Bug libstdc++/29037] performance problem with std::string operator=(const std::string& str);

[neundorf at kde dot org]

------- Comment #9 from neundorf at kde dot org  2006-09-12 20:51 -------
> > Starting to think about weird hacks:
> > how about keeping the shared-data during string assignment as it is now
> > but additionally keep a pointer to the eventually already allocated buffer
> > around,
> > so that it can be reused as soon as copy-on-write is required ?
>
> I see this point too, I have been thinking about something along those
> lines, but you understand that we have an ABI, which we *must* keep
> absolutely stable,

Yes, I understand.
But... don't you have a "private d-pointer" or pimple or however it is called ?
Ok, this would mean that in every case at least one malloc/new would be
required when creating a string object, which you maybe wanted to avoid...

> All in all, I'm inclined to believe that your PR has a point of course but
> we cannot really fix the issue, we cannot improve the current string class
> the way you would like. Any objections to closing it as WONTFIX?

No, no objections.
Thanks for the kind explanations :-)
Alex


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29037