Re: Return versus Side-Effect
On 30 Mrz., 21:41, Alberto Ganesh Barbati <AlbertoBarb...@libero.it>
wrote:
Daniel Kr?gler ha scritto:
Unfortunately, that would break a lot of existing valid code and
precisely all code using the so-called swap-trick, for example:
std::vector<int> v;
std::vector<int>().swap(v);
(notice that you can't write the trick the other way round, because
rvalues are currently not allowed as the function parameter)
The swap-trick has been advertised as the right way to deallocate a
vector's buffer (it's described even in Scott Meyers' EC++ Programming).
Making it illegal would be a suicide, IMHO.
Sorry for my misleading formulation. I did not mean to say that the
standard library *should* change their member swap signature,
therefore I tried to be careful enough to write "that would
programmers
allow to prevent the above mentioned current asymmetry, if they don't
like them".
Nevertheless I do not see serious reasons if a programmer should
decide to strengthen his/her own member swap signature as described.
In this case one would have to modify your example to
std::vector<int> v;
v.swap(std::vector<int>());
IMO it would be safe to do that in general, even for the standard.
But that would create nasty backward compatibility problems, because
users would need to rewrite earlier valid code, which is maybe the
most severe reason against it.
On the other hand, the very recent paper n2590
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2590.pdf)
argues whether it's so wrong to allow rvalues on both sides of the swap.
The paper proposes to replace all the swap overloads for the too many
library classes with just one restricted template:
template <ClassType T>
auto concept MemberSwappable {
void T::swap(T &&); // notice: rvalues allowed on both sides
};
template <MemberSwappable T>
void swap(T&& a, T&& b) {
a.swap(b);
}
I don't know the reputation of the proposal and its chance to be
accepted, but the idea of removing 30+ groups of three identical
std::swap overloads from the library sounds a good thing to me, do you
agree?
I also have no idea about the reputation of that proposal, but I
totally agree with it's approach.
Btw.: I was also very happy to see that your proposal (now in 1st
revision:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2568.pdf
) - which we earlier discussed on comp.std.c++ - has got a seemingly
good resonance. If I take a look on comp.std.c++ it seems as if
time has been frozen here, indeed the enumeration proposal was
the last one accepted - I hope that it did not lead to an infection
of the central nervous system of the internet... ;-)
Greetings from Bremen,
Daniel
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]