Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-07-28 16:11:25

----- Original Message -----
From: "Aleksey Gurtovoy" <alexy_at_[hidden]>

> Jeremy Siek wrote:
> > Are you worried about the "swap" problem?
> Yes, I don't trust overload resolution process too much :), if that's what
> you are asking. The more overloads you have, the bigger are chances that
> some point you'll have to deal with (unwanted :) ambiguity.

So, we're back to the Lib 225/229 issue again! The problem has raised its
ugly head breathtakingly often of late.

I think we need to discuss the alternatives, do some experiments and
establish some existing practice in this domain. We could make a
contribution to the standards process in this area by moving forward
ourselves; at least we are unencumbered by std:: backward-compatibility
problems and may be able to make more progress than the committee for that

To begin the discussion:

I worry that even dispatching through a function template to arrive at a
specializable class template may be problematic: the point where the
compiler realizes it's handling a type for which the algorithm was not
intended may come too late (inside the dispatching function). In other
words, the technique is fine for users who explicitly /want/ their type to
work with some library algorithm: they just specialize the implementation
class template. The technique might not be fine for users who /didn't/
intend the library algorithm to work with their types... I'm being a little
vague here because I don't have concrete examples of potential trouble (i.e.
I might be full of FUD).

Anyway, another technique we ought to consider is that of /embracing/
overload resolution instead of avoiding it. Since some functions can only be
called without qualification (see the Barton & Nackmann technique used by
the operators library), it might be better to use a special tag type to
indicate which library's semantics are intended:

template <class S>
typename boost::sequence_traits<S>::iterator begin(S const&, boost::tag);

So instead of boost::begin(s) we're going to call begin(s, boost::tag())

Of course, if you try to make that more convenient by adding:

  namespace boost {
    template <class S>
    typename boost::sequence_traits<S>::iterator begin(S const& s)
        return begin(s, boost::tag);

Then we have at least the original problem (?) of late discovery that
begin() wasn't supposed to work on a given type. Even so, it means that the
B&N trick can be used to generate algorithm "specializations", which could
be especially important on compilers that don't support partial


Boost list run by bdawes at, gregod at, cpdaniel at, john at