Re: Swappable concepts and ADL
Niels Dekker - no return address ha scritto:
Hmmm... I believe that doing a.swap(b) should always be equivalent to doing
swap(a,b)! IMO, the member and the non-member swap function should be kept in
sync. So for a template class that allows customizing its non-member swap,
having the member swap call the non-member swap appears The Right Thing To Do.
I don't know about swap(a,b), all I care is std::swap(a,b) ;) According
to my proposal if the type is MemberSwappable then std::swap(a,b) is
equivalent to a.swap(b) *except* when an explicit Swappable concept_map
is provided. It might not be unconceivable to provide a different
proposal where MemberSwappable takes precedence over a Swappable concept
map, but do we really want that?
The user is expected to always call std::swap(), by doing so she would
always get the best swap method available.
Member swap() should be an ingredient of the std::swap() recipe, users
should use the recipe, not the ingredient directly, unless they know
what they're doing.
Well, at least it's clear that your C++0x std::swap would come with a new set
of user guidelines. As long as the member swap remains a public member
function, it's hard to tell the user not the call it. In "old" C++03 it was
actually even recommended to prefer calling member functions to algorithms
with the same names! Scott Meyers, Effective STL, item 44,
http://www.informit.com/content/images/0201749629/items/item44-2.pdf
Yes, I know that. But that recommendations were about specific types or
templates (containers in particular) and not about truly generic
programming. For "known" types, it is conceivable that no explicit
Swappable concept_map exists: in that case the choice among the two is
equivalent. In generic code, however, std::swap might be preferable, at
least because you don't know in advance whether a swap member is available.
Moreover, in C++03, the swap member function is the only one that provides
swapping a temporary.
That would no longer be an issue in C++0X :)
I tried ConceptGCC and if the swap() member is private, then the class
silently fails to satisfy the MemberSwappable concept. That's what you
(and me) expected and that's good news!
Cool :-)
So, are you going to write another proposal?
I would like to, but maybe I should get some more feedback about a few
controversial points before doing it.
Thanks!
Ganesh
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]