--- 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
> >
--- Comment #7 from neundorf at kde dot org 2006-09-12 20:34 ---
...
> "problematic" are string assigns, not += and you are moving the reserve
> *after* the assign.
Yes, but in the every assign the capacity would still be lost. This would mean
the reserve would happen
--- Comment #5 from neundorf at kde dot org 2006-09-12 17:55 ---
std::string cacheKey;
for (...several files...)
{
cacheKey=current.FileName;
cacheKey.reserve(4*1024);
for(std::vector::const_iterator i =
this->IncludePath->begin(); i != this->IncludePath-&g
--- Comment #2 from neundorf at kde dot org 2006-09-12 17:04 ---
The use case here is as follows:
std::string cacheKey;
cacheKey.resize(4*1024);
for (...several files...)
{
cacheKey=current.FileName; // <- this is the critical line
for(std::vector::const_iterator i =
t
std::string& str);
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neundorf at kde dot org
h
