Re: [boost] iterator adaptor named parameters

From: Jeremy Siek (jsiek_at_[hidden])
Date: 2001-06-04 09:19:26

On Sun, 3 Jun 2001, David Abrahams wrote:
>
> None that I love much better:
>
> boost::parameter::value_type<T>

This one is nice in that the user can do a "using" in function
scopes...

> boost::value_type_is<T>

And this one has a nice ring to it, better readability. Let's
go with this one.

> boost::specify_value_type<T>

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

Sure.

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

Just for my debugging, I'll delete the #if.

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

Yes.

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

Sounds like you want me to turn the named parameter header into a "public"
and reusable peice of code ;) I hadn't planned on that, but OK, fair
enough. It will take some more time to figure out exactly how to do this,
and write up the docs.

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

Thanks,
Jeremy

----------------------------------------------------------------------
 Jeremy Siek                        www: http://www.lsc.nd.edu/~jsiek/
 Ph.D. Candidate, IU B'ton          email: jsiek_at_[hidden]
 Summer Manager, AT&T Research      phone: [phone]
----------------------------------------------------------------------