Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-03-07 06:40:48


From: "Aleksey Gurtovoy" <alexy_at_[hidden]>

[...]

> First of all, it's not about simulating the missing feature, it's about
> solving the real problem in an acceptable way. Second, I don't think that
>
> iterator_traits_builder
> ::value<dummyT>
> ::reference<const dummyT&>
> ::category<std::forward_iterator_tag>
> ::distance<std::ptrdiff_t>
> ::pointer<const dummyT*>
> ::type
>
> is so much different from
>
> iterator_traits_builder<
> value = dummyT
> , reference = const dummyT&
> , category = std::forward_iterator_tag
> , distance = std::ptrdiff_t
> , pointer = const dummyT*
> >
>
> IMO they are pretty much equivalent in both readability and ability to
> express the code intent.

Excuse me for jumping in the middle of the discussion - and without fully
understanding the issues involved, at that. :-)

Isn't the above building the std::iterator_traits specialization? If so,
what's wrong with

struct my_iterator_traits: public default_const_iterator_traits<dummyT>
{
    typedef std::forward_iterator_tag iterator_category;
};

The idea being that (only) the non-defaults are explicitly replaced by
typedefs. The function case differs in that functions cannot inherit each
other. :-)

Perhaps I'm missing something...

--
Peter Dimov
Multi Media Ltd.

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