Re: [boost] iterator adaptor named parameters

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-06-03 16:28:31

----- Original Message -----
From: "Jeremy Siek" <jsiek_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, June 03, 2001 4:55 PM
Subject: Re: [boost] iterator adaptor named parameters

> On Sun, 3 Jun 2001, David Abrahams wrote:
>
> > I don't love the _p suffix, but otherwise, this is roughly what I'd
> > envisioned.
>
> Do you have any suggestions on an alternative for "_p"?

None that I love much better:

boost::parameter::value_type<T>
boost::value_type_is<T>
boost::specify_value_type<T>

> > I don't see why everything needs to be wrapped and stuck into an
> > associative list, but I'm not looking at the implementation details
here.
>
> The list is needed so that the parameters can come in any order. I'll
> attach my new version of iterator_adaptors.hpp and
> named_template_params.hpp. Look at the iter_adaptor_traits_gen class and
> the use of find_param.

Okay. Comments:

1. The NTP declaration macro is now simple enough that I strongly believe it
should be eliminated.

2. Why is this section of iterator_adaptors.hpp #if 0'd out?

if 0
    BOOST_STATIC_CONSTANT(bool, is_input_or_output_iter
          =
(boost::is_convertible<iterator_category*,std::input_iterator_tag*>::value
             ||
boost::is_convertible<iterator_category*,std::output_iterator_tag*>::value))
;

    // Iterators should satisfy one of the known categories
    BOOST_STATIC_ASSERT(is_input_or_output_iter);

    // Iterators >= ForwardIterator must produce real references
    // as required by the C++ standard requirements in Table 74.
    BOOST_STATIC_CONSTANT(bool, forward_iter_with_real_reference =

(!boost::is_convertible<iterator_category*,std::forward_iterator_tag*>::valu
e
           || boost::is_same<reference,value_type&>::value
           || boost::is_same<reference,const value_type&>::value));

#if !defined(BOOST_MSVC)
    // This check gives incorrect results in iter_traits_gen_test.cpp
    BOOST_STATIC_ASSERT(forward_iter_with_real_reference);
#endif
#endif

3. The approach used in named_template_params.hpp to compute defaults seems
somehow too specifically aimed at iterator_adaptors. Even if we accept that,
I think this comment may be wrong:

    // This macro assumes that there is a class named default_##TYPE
    // defined before the application of the macro.  This class should
    // have a single member class template named "bind" with two
    // template parameters: the type of the class being created (e.g.,
    // the iterator_adaptor type when creating iterator adaptors)

specifically, that last part. In our case, the first parameter is the base
type being adapted, right?

    // and
    // a traits class. The bind class should have a single typedef
    // named "type" that produces the default for TYPE.  See
    // boost/iterator_adaptors.hpp for an example usage.  Also,
    // applications of this macro must be placed in namespace
    // boost::detail.

And why a "traits class"? Nowhere do you say what should be done with it. I
suggest there should be a single type parameter; pass a type list or type
pair for iterator_adaptors. In any case, the code is still quite unclear.
Can you put the implementation details at the bottom and the high-level
stuff near the top? Can you improve the comments? I'm still afraid of what
happens when I have to debug this.

Not to discourage you; I think it's getting better.

Regards,
Dave