Re: std::string::reserve vs std::vector::reserve

[Jonathan Wakely <cow at compsoc dot man dot ac dot uk>]

On Thu, Jun 16, 2005 at 01:29:14PM +0200, Paolo Carlini wrote:

> Jonathan Wakely wrote:
> 
> >The standard was written explicitly so that COW strings would be
> >possible (some implementors have since objected that it's worded to make
> >non-ref-counted strings too difficult!)
> >
> >The only requirement on std::string::operator= is that capacity() should
> >return "a value at least as large as size()", which libstdc++'s
> >implementation does.
> >
> I only want to add that, in a non-COW implementation (for instance, the
> current default in v7-branch), it would be trivial to change that
> behavior and I even considered that a couple of days ago. However, I'm
> not sure there is agreement among the implementors about the ""best""
> behavior (from a QoI point of view): AFAIK, some non-COW implementations
> also don't retain the capacity of this (when >= the needed one, of course)

So to summarise, the standard doesn't place any strict requirements on
the behaviour, so it is best not to assume anything more than
"capacity() will always be greater than or equal to size()" for strings.

>>             Will one day vector behave likewise ?
>
> No. Absolutely not.

Actually ...
It occurs to me that it is possible that vectors capacity could change
after an assignment, when we implement move semantics:

    std:vector<int> v;
    v.reserve(100);
    v = std::vector<int>();

That would change the capacity, since the temporary would bind to the
rvalref and the implmenetations would be swapped.  Should we retain the
old capacity in this case?

e.g.

      vector&
      operator=(__gnu_cxx::__rvalref<vector> __x)
      {
        this->swap(__x.__ref);
+       this->reserve(__x.capacity());
        return *this;
      }

jon


-- 
"Strange how potent cheap music is."
	- Noël Coward