Re: Boost algorithm library (Was: [boost] New upload: algorithm.z ip 1)

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
at
> 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
reason.

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
specialization.

-Dave