RE: [boost] Re: Tuples Library Formal Review

From: Gary Powell (Gary.Powell_at_[hidden])
Date: 2001-06-19 16:58:42

[Jaakko Jarvi]
Wow, what a lot of comments!
[Gary]
 Yeah Wow!

[Gary]
I'll try to answer some more of these.

[snip]

[Vesa Karvonen]
> - Could get() implementations be simplified by moving the 
metafunction call
> typename element_type<...>::type into the access_traits?
>
[Gary]
Maybe, we'll have to look at that.
 
> - Could logic duplication be reduced in tuple_comparison.hpp?
[Gary]
Yes and no.
If a user type has overloaded the operators, then they should be called.
My understanding is that if they have not, then rel_ops, will generate the
missing comparison operators.

> 
> - Should TAB characters in tuple_basic_no_partial_spec.hpp be 
replaced with
> spaces?
[Gary]
Yes, Sorry, it's my editor.
> 
> - Should all headers included by tuple.hpp check that they are not 
included
> separately?
No.
Detail includes are not for general consumption. tuple_io.hpp already
includes tuple.h, and tuple.h does not require tuple_io.hpp
So yes too,
as in we should add it as a benefit to the user. (But its not required that
we 
do so.)

> 
> - Should map_tuple_to_cons<> have the same interface for both with 
and without
> partial specialization? 
[Gary]
Yes, opps.

If not, should it be in the detail 
namespace?
> 
> - The tie and make_tuple implementations are highly repetitive. 
Wouldn't it be
> possible to reduce the code size significantly, for instance, by 
moving the
> repeated metafunction calls inside an auxiliary metafunction?
[Gary]
But would the greater level of nesting of templates prevent compiliers from
generating code? My understanding is that 17 is the suggested upper limit.
With LL and gcc, we are often near 50.

> 
> - Is "explicitely" a type in the code comments?
[Gary]
Ah no, its a typo.
> 
> - Could implementation be shared between partial and non partial
> specialization versions? Should that be done?
[Gary]
As Doug mentioned, no. The non partial version should be easily dumped when
the lowest common compiler finally gets it right.

> 
> - Would it be useful to have a clearly specified and documented
> metaprogramming interface for creating and accessing tuples?
[Gary]
What are you thinking? I'm a bit confused by this request.

> 
> - How can a metaprogram compute a tuple type based on a variable 
length type
> list or otherwise computed set of types? Can the process be 
simplified?
[Gary]
I think this was addressed in John's reply, but its
element<N, T>::type
> 
> - How can a metaprogram compute the type of the Nth element of a 
tuple? Should
> this be documented?
[Gary]
Needs to be documented. Thanks.

> 
> - How can a metaprogram detect that a type parameter is a tuple 
type? Should
> this be documented?
[Gary]
Partial specialization would be my choice. Should this be added to the
typetraits?
> 
> - How can a metaprogram compute the number of elements of a tuple? 
Should this
> be documented?
[Gary]
Yes, and tuple_length<t>::value
> 
> - Would it be useful to provide a manipulator for changing all the
> configurable behaviour of tuple streaming at once?
[Gary]
Yes, but I prefer the individual method, less code for us to write. :>
No seriously does anyone else want this?

> 
> 
> Additional comments
> ===================
> 
> Lexicograhical ordering is not the only useful ordering model. Other
> frequently useful models include:
> - ordering based on only a subset of elements (e.g. key-value pair)
>   - note: std::map<K,V>::value_type suffers from this problem
>   - for this reason, I use neither tuple nor pair in my container 
library.
> - dominance:
>     A<B if a(i)<b(i) for all i
[Gary]
I'm not sure how to address this for all other models. Suggestions?

And again thanks for all the comments. If I have muddied the water, just
throw these back at me with more elaboration.

  Yours,
 -gary-

gary.powell_at_[hidden]