A while ago I posted about vector::resize – how it takes a parameter by value and thus cannot store aligned elements. I confessed I didn’t understand Stephen Lavavej’s words:

…There’s a reason that our resize() is currently taking T by value – it guards against being given one of the vector’s own elements …

Some interpretations were suggested by commenters, but the mystery pretty much remained. In the last few days, a StackOverflow post –which I can’t find now – led me to Standard Library Defect #679:

The C++98 standard specifies that one member function alone of the containers passes its parameter (T) by value instead of by const reference:

void resize(size_type sz, T c = T());

This fact has been discussed / debated repeatedly over the years, the first time being even before C++98 was ratified. The rationale for passing this parameter by value has been:

So that self referencing statements are guaranteed to work, for example:

v.resize(v.size() + 1, v[0]);

However this rationale is not convincing as the signature for push_back is:

void push_back(const T& x);

And push_back has similar semantics to resize (append). And push_back must also work in the self referencing case:

v.push_back(v[0]);  // must work
…

In the former post I noted that since gcc does implement vector::resize with a by-reference argument, and so wrongfully concluded that the by-value argument is an MS issue. Turns out it is (well, was) a C++ standard acknowledged issue – and unlike gcc, MS were being strictly conformant. You could say, though, that MS did implement large parts of C++0x in VS2010 and they might have squeezed in this standard correction – but fact is they didn’t and since it isn’t yet a standard it isn’t yet a bug.

Either way, Stephen’s words make sense now. I still think, however, that the current implementation can take a const reference as is, and I can’t see any further internal changes required.  (Than again, that is probably part of the reason that I’m not the one maintaining MS’s STL…).