Date: 2001-06-19 12:10:21
Wow, what a lot of comments!
> "To use the library, just
> #include "boost/tuple/tuple.cpp"
> - Should ".cpp" be ".hpp"? (The same question for other cases in the
> - Should boost headers use the #include <> form?
This seems to be the boost convention, and we can change to that.
(We were once adviced against this by Stroustrup, the claim
was that using <> was somehow non-standard. We took his word
and didn't think it further.)
> "The code:
> tuple i;
> tuple j;"
> - Are the variable definitions of i and j as intended?
Nope, will be fixed.
> - Is the name "Droug Gregor" spelled correctly?
Nope, will be fixed.
> Design & Implementation
> - Should include guards have the word TUPLE in them to distinguish
> other Boost headers?
The intention was that they would be of the form
I'll check that they all are.
> - Should the separation between interface and implementation of the
> made clearer?
Can you be more specific.
> - Should IF<> and other implementation helpers be in the detail
Ok. Or I'd really like to use a boost metaprogramming library
when that becomes official :)
> - Are cons and nil part of the interface of the library? Should they
> documented? What about documenting other stuff not placed into the
cons is part of the library.
Sometimes you may want to use the cons list view to the tuple,
for instance while writing functions that operate on tuple
elements (see tuple_io or the comparison operators).
nil is part of the interface in the sense, that the cons list
type of an empty list is nil (once we add the empty tuple,
and change the name of nil to something else)
Other non-detail stuff will be documented.
> - Should a separate forward declaration header, e.g. tuple_fwd.hpp,
> introduced to help avoid unnecessary compile time dependencies?
> - Could void be used instead of nil? If not, why not? Using void
> the interface a bit. Would the changes have adverse effects?
No, we need to be able to provide actual objects as default arguments
in the tuple constructor.
> - If all tuple template type parameters, and the second type
> cons, were nil by default, would it be possible to remove nil from
I must think of this. Maybe, unless we want nil to be the underlying
cons list for the empty tuple.
> - Should the number of elements that Tuple supports be easily
We had a set of macros for this, your preprocessing library could
be of help in this.
What do others say?
> - Should indexing from 0 to n-1 be supported? Isn't 0-based indexing
> intuitive in C++?
This is a matter of taste. Others?
> - Should element_type<> use private to hide the Next type? What
> issues in other implementation classes?
I must stop here, as I'm out of time for today.
Thanks a lot for the comments,
> - Could get() implementations be simplified by moving the
> typename element_type<...>::type into the access_traits?
> - Could logic duplication be reduced in tuple_comparison.hpp?
> - Should TAB characters in tuple_basic_no_partial_spec.hpp be
> - Should all headers included by tuple.hpp check that they are not
> - Should map_tuple_to_cons<> have the same interface for both with
> partial specialization? If not, should it be in the detail
> - The tie and make_tuple implementations are highly repetitive.
Wouldn't it be
> possible to reduce the code size significantly, for instance, by
> repeated metafunction calls inside an auxiliary metafunction?
> - Is "explicitely" a type in the code comments?
> - Could implementation be shared between partial and non partial
> specialization versions? Should that be done?
> - Would it be useful to have a clearly specified and documented
> metaprogramming interface for creating and accessing tuples?
> - How can a metaprogram compute a tuple type based on a variable
> list or otherwise computed set of types? Can the process be
> - How can a metaprogram compute the type of the Nth element of a
> this be documented?
> - How can a metaprogram detect that a type parameter is a tuple
> this be documented?
> - How can a metaprogram compute the number of elements of a tuple?
> be documented?
> - Would it be useful to provide a manipulator for changing all the
> configurable behaviour of tuple streaming at once?
> 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
> - dominance:
> A<B if a(i)<b(i) for all i
> ----- Original Message -----
> From: "Beman Dawes" <bdawes_at_a...>
> To: "Boost.org mailing list" <boost_at_y...>;
> Sent: Sunday, June 17, 2001 17:13
> Subject: [boost] Tuples Library Formal Review
> > The Formal Review period for Jaakko Järvi's Tuples library begins
> > and runs through Tuesday, June 26th.
> > The library is available at
> > For information about submitting a Formal Review, see
> > http://www.boost.org/more/formal_review_process.htm
> > Be sure to say whether or not you think the library should be
> > Boost.
> > The Formal Review manager is Beman Dawes.
> > --Beman
> > Info: http://www.boost.org Unsubscribe:
> > Your use of Yahoo! Groups is subject to
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk