[Bug libstdc++/20114] Non-monotonic behavior of string::reserve

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-03-31 20:57 
---
*** Bug 20706 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||ftr at highstreetnetworks
   ||dot com


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

[Bug libstdc++/20114] Non-monotonic behavior of string::reserve

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-02-20 22:18 
---
Note that, according to the standard, after a call to reserve(n), the *only*
guarantee is that capacity = n. I'm going to look a bit into this, but will
change the current behavior, which results from the interaction for very special
values of n of two well founded strategies - standard mandated exponential grow
policy + smart requests to malloc - only if a fix is *really* clean.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-20 22:18:41
   date||


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

[Bug libstdc++/20114] Non-monotonic behavior of string::reserve

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-02-20 22:57 
---
Humm, actually the fix seems very simple and also cures an old itch of mine,
thanks for this! We should just call _S_create passing the current size *not*
capacity as the second argument. Stay tuned...

-- 


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

[Bug libstdc++/20114] Non-monotonic behavior of string::reserve

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-02-21 02:54 
---
Not a but, really, not even of QoI type. What's going on is that your fourth
reserve, reserve(8165), actually asks for a capacity which is *lower* than the
current one (i.e., 16355), that is, in standard terms, a non-binding shrink
request. Until 3.3 we completely disregarded those, as the standard allows, but
lately many people requested to honor those requests: indeed, trimming excess
allocated memory can be useful (look for Ferguson in the archives). Actually,
4.0.0, after a recent tweak of mine, goes even further and shrinks more, down to
8165, for your testcase.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||INVALID


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