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

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-07-29 11:43:07

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

> This is _very_ interesting, Dave! I've read your proposal before, but
didn't
> have time to really thought about it. Now, when I did spend some time on
it,
> I can say that I find it quite appealing.
>
> A few minor problems that I see:
>
> 1) Library author(s) should always remember to use unqualified names for
> dispatching functions (begin(s, boost::tag)), and qualified names for
> top-level interface functions (boost::begin(s)) when they are used
> internally by the library itself.

Examples, please, and reasoning? I don't understand what you're saying
above.

> Given that (at least without proper tests)
> failure to do so won't result in an immediate compile-time error, chances
> are that this could become a common source of subtle bugs. Also, if both
> forms are "co-located", the "inconsistency" can be confusing,
>
> template<class Sequence>
> inline
> bool empty(Sequence& seq, boost::tag_t)
> {
>     return boost::begin(seq) == boost::end(seq); // ok
> }
>
> template<class Sequence>
> inline
> bool empty(Sequence& seq)
> {
>     return empty(seq, boost::tag); // ???
> }
>
> and there is a possibility that one day someone would "fix" it.

Still confused about what you're getting at. Which namespace are these in?

> 2) Unfortunately, Koenig lookup seems to fall into the same category of
> language features as partial specialization of class templates - there are
> still some popular compilers that do not implement it in full; in
> particular, MSVC supports it only for operator functions. It means that if
> we are going to use the technique in its original form, it would be
> effectively impossible for users of such compilers to provide any
> "specializations" of library's default algorithms. Of course, there are
some
> ways around this issue. For example, instead of
>
> template<class Sequence>
> inline
> typename boost::sequence_traits<Sequence>::iterator
> begin(Sequence& seq, boost::tag_t)
> {
>     return seq.begin();
> }
>
> template<class Sequence>
> inline
> typename boost::sequence_traits<Sequence>::iterator
> begin(Sequence& seq)
> {
>     return begin(seq, boost::tag);
> }
>
> one can write this:
>
> struct begin_algorithm_tag {};
>
> template<class Sequence>
> inline
> typename boost::sequence_traits<Sequence>::iterator
> operator%(Sequence& seq, boost::begin_algorithm_tag)
> {
>     return seq.begin();
> }
>
> template<class Sequence>
> inline
> typename boost::sequence_traits<Sequence>::iterator
> begin(Sequence& seq)
> {
>     return seq % boost::begin_algorithm_tag();
> }
>
> Given that difference between "operator%(Sequence& seq,
> boost::begin_algorithm_tag)" and "begin(Sequence& seq, boost::tag_t)" can
be
> hidden behind a macro, it's not that bad as it might seem at first sight
:)

Yikes!
Even so, I hope we can find another approach for MSVC et. al.

-Dave