Boost logo

Boost :

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:


> > 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
> 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

    // Iterators should satisfy one of the known categories

    // 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_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

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at