Boost logo

Boost :

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2005-05-04 16:27:24


Hello, although this is more of a std issue than
a Boost one, I think it has some nice implications
for some Boost libraries, so please allow me
to post it here (also, my original proposal
at comp.std.c++, http://tinyurl.com/7wjyl, got
almost zero response.)

The proposed resolution N1523

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1523.htm

aims at settling down the issue of whether
some std algorithms are required/allowed to
call user-provided overloads of swap(): by requiring
that internall calls to swap are unqualified, a whole
range of algorithms (swap_ranges, reverse, rotate, etc.)
are automatically extended to cover types modeling
the "swappable" concept: this includes assignable types
but also non-assignable types for which a suitable
swap() overload is provided.

Now, my proposal tries to extend the applicability
of these algorithms by adding an extra level of
indirection: instead of requiring that swap() is
unqualifiedly called, let us mandate that swapping
be performed by an unqualified call to iter_swap().
Also, make the definition of std::iter_swap()
unqualifiyingly call swap(). What does this
buy us? In the general case, the situation is exactly
the same as proposed in N1523, but the extra level
of indirection allows us to overload iter_swap()
in cases where the pointed-to types are not
even swappable. A paradigmatic case of use is
Boost.PtrContainer: the types held in this kind
of containers are in general not swappable, but
an iter_swap() overload than simply exchanges the
internal pointers makes a lot of sense: the
overall result is that rotate, reverse, etc.
will work as expected, save the minor detail that
this "extended swap" concept does not work as
usual with raw pointers to the ext-swapped elements
--only iterators to the elements get their
pointed-to elements interchanged.

What do you think of this? IMHO this can solve
the problem of making std swapping algorithms
work with ptr_containers, a problem for which
(if I'm not wrong) no satisfying solution has been
designed.
My selfish interest in this proposal stems from the
fact that a vector-like type of indices I'm
designing for Boost.MultiIndex would also benefit
from this.

If the idea is well accepted, maybe we can
provide Boost implementations of these algorithms
taking proper care of unqualifyingly call
iter_swap(). Ideas, comments etc. are most welcome.

Thank you,

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk