
Boost : 
From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 20010728 15:32:26
Jeremy Siek wrote:
> > template<class Sequence>
> > struct begin_algorithm
> > {
> > typedef typename sequence_algorithm_traits<Sequence>::iterator
> > result_type;
> > static result_type result(Sequence& seq)
> > {
> > return seq.begin();
> > }
> > };
> >
> > template<class Sequence>
> > inline
> > typename begin_algorithm<Sequence>::result_type
> > begin(Sequence& seq)
> > {
> > return begin_algorithm<Sequence>::result(seq);
> > }
>
>
> I'm curious, what's the reason for the added complexity here? Why not
> just:
>
> template <class Sequence>
> typename sequence_traits<Sequence>::iterator
> begin(Sequence& s)
> {
> return s.begin();
> }
>
> and then let people overload begin() for unusual sequence
> types? 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. IMO
specialization is a more "right" way to deal with, well, special cases, and
as we don't have partial specialization of function templates, class
templates like 'begin_algorithm' from the above code are the only way to do
it. Also, having the only one "entrance point" for every algorithm helps
when you have to deal with compilers that do not support partial ordering of
function templates (MSVC, for one).
Aleksey
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk