From: jaakko.jarvi_at_[hidden]
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
> documentation.)
Ok.
>
> - 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
them from
> other Boost headers?
The intention was that they would be of the form
BOOST_TUPLE_...
I'll check that they all are.
>
> - Should the separation between interface and implementation of the
library be
> made clearer?
Can you be more specific.
>
> - Should IF<> and other implementation helpers be in the detail
namespace?
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
be
> documented? What about documenting other stuff not placed into the
detail
> namespace?
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,
be
> introduced to help avoid unnecessary compile time dependencies?
Ok.
>
> - Could void be used instead of nil? If not, why not? Using void
might change
> 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
parameter to
> cons, were nil by default, would it be possible to remove nil from
library
> interface?
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
configurable?
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
more
> intuitive in C++?
This is a matter of taste. Others?
>
> - Should element_type<> use private to hide the Next type? What
about similar
> issues in other implementation classes?
Ok.
I must stop here, as I'm out of time for today.
More later.
Thanks a lot for the comments,
Jaakko
>
> - Could get() implementations be simplified by moving the
metafunction call
> 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
replaced with
> spaces?
>
> - Should all headers included by tuple.hpp check that they are not
included
> separately?
>
> - Should map_tuple_to_cons<> have the same interface for both with
and without
> partial specialization? 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?
>
> - 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
length type
> list or otherwise computed set of types? Can the process be
simplified?
>
> - How can a metaprogram compute the type of the Nth element of a
tuple? Should
> this be documented?
>
> - How can a metaprogram detect that a type parameter is a tuple
type? Should
> this be documented?
>
> - How can a metaprogram compute the number of elements of a tuple?
Should this
> 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
library.
> - 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...>;
> <boost-announce_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
today,
> > and runs through Tuesday, June 26th.
> >
> > The library is available at
> >
http://groups.yahoo.com/group/boost/files/Tuple/tuple-2001-05-29.zip
> >
> > 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
accepted by
> > Boost.
> >
> > The Formal Review manager is Beman Dawes.
> >
> > --Beman
> >
> >
> > Info: http://www.boost.org Unsubscribe:
> <mailto:boost-unsubscribe_at_y...>
> >
> > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
> >
> >
> >