Boost logo

Boost :

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

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


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


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


 Jeremy Siek www:
 Ph.D. Candidate, IU B'ton email: jsiek_at_[hidden]
 Summer Manager, AT&T Research phone: (973) 360-8185

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