STL last arg to vector::resize

[John L. Kulp]

Can anyone give me the rationale about why vector::resize passes its last argument by value?  On the surface it seems wrong to incur the cost of copying for no reason I can see. Also, MSVC and gcc disagree about whether the arg should be const.  Again, is there any reason it shouldn't be?  Perhaps this has been discussed, in which case could someone point me to that?  Thanks.  Note that passing by value means that aligned vectors as required for SSE code will fail to compile due to this.


John L. Kulp wrote:

> > Shouldn't the last (optional) argument be (1) const and (2) a reference
> > (rather than a potentially very expensive copying call-by-value)?  Among
> > other things, if you have a type declared with alignment attributes, it
> > will fail on this.  I notice the MSVC implementation has (1) but not
> > (2).  I can't see any code that would depend on the value being copied.
>   

The standard specifies the signature. Making it const doesn't change
the signature, so that's conforming, but doesn't avoid the copy.
Making it a reference would be non-conforming.

If copy constructions are very expensive then maybe storing the types
in std::vector directly isn't a good idea. You could store them by
(smart) pointer instead, or just use capacity and push_back instead of
resize. Calling resize(n) could result in n copy constructions, so one
more for the parameter isn't going to matter in many cases.

If you remain unconvinced you might want to take the thread to
libstdc++@gcc.gnu.org rather than this list, but I'm certain noone
will change that signature while the standard says it passes by value.

Jon