From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2001-03-05 02:42:49
Jeremy Siek wrote:
> So I'm in favor of going with the following
> interface style (suggested by someone in an earlier email):
> >::type Iter;
IMO this is very nice!
One small concern, though: I would like to see
'boost::iterator_adaptor_types' to be named along the lines of
(non-existent) 'boost::iterator_traits_builder', for two reasons:
1) 'builder' suffix reminds one to write '::type' at the end of the '::'
chain; it's true that if you forget the compiler will let you know :), but
it's still a nice convention that worked well for me;
2) IMO 'iterator_traits' part gives you more explicit hint about naming of
the "parameters" than 'iterator_adaptor_types' does.
Disadvantage of the particular 'iterator_traits_builder' name is that it is
so generic that one can think that
typedef std::iterator<random_access_iterator_tag, int> Iter;
should give the same result (in terms of defined nested typedefs), which is,
of course, not true. However, on second thought, I don't think that such
assumption is valid at all; it would be if the class was named
'boost::std_iterator_builder' or something alike, but
'iterator_traits_builder' seems to be not bad after all..
> The trick with getting this approach right, as Dave pointed
> out, is that the creation of defaults can only happen for
> types that are suppose to be defaulted. I've attached a file
> that does this. I've done a quick check to make sure it
> works for VC++ and g++. The file creates a
> iterator_adaptor_generator class... it should be
> straightforward to apply the same technique to
> iterator_adaptor itself.
A small issue with the code - we don't need a semicolon after
BOOST_NAMED_TEMPLATE_PARAMETER macro invocation, and CW6.1 issues the
"illegal empty declaration" warning for it:
boost::detail::default_value_type); // not needed here
Besides this, it all looks great!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk