Re: [boost] Re: Tuples Library Formal Review

From: Vesa Karvonen (vesa.karvonen_at_[hidden])
Date: 2001-06-20 05:22:29

From: "Gary Powell" <Gary.Powell_at_[hidden]>

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

hmn... I agree that this can be a problem. However, 17 is too low, IMHO, for
many interesting things. Perhaps we need a more robust metaprogramming
language...

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

Yes, I agree with this in general. I was thinking of the possibility of making
some of the services separately accessible rather than as parts of the tuple
implementation. However, I have not analyzed which services would be useful,
if any, without the tuple.

I typically prefer small headers, because I have observed that I rarely need
every definition in a header that has multiple definitions. Small headers make
it possible to avoid unnecessary dependencies.

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

The 3 questions following this one detailed this issue. The basic idea is that
I would like to be able make metaprograms that can manipulate tuples. For
example, I want to make it possible to create a tuple based on a type list.
Another example is that I want to make it possible to compute a reference
tuple (tie) based on a value tuple (make_tuple).

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

hmn... If I understand it correctly, then element<N,T>::type is the answer to
the next question. However, I was think of the following kind of situation:

    template
    < class type_list
    >
    struct make_tuple_type_from_type_list
    { typedef typename
        /* the question was about this part */
          type;
    };

I think that the above meta function should either be directly provided, or be
made easy to implement on top of the tuple library. I have multiple
applications in mind for the above metafunction.

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

(I assume that you mean that the metafunction would be added to the type
traits library rather than the tuple library, but due to the ambiquities, I'm
not sure this is what you intended.)

I would generally add library specific metafunctions directly into the library
rather than some other library, because it simplifies dependencies. Adding the
facility to typetraits library would probably result in cyclic dependencies
between the libraries.

    template
    < class any
    >
    struct is_tuple
    { static const bool value = ???;
    };

However, I'm not exactly sure when I would need this metafunction. It might be
useful sometimes, but I don't have a specific application in mind, so I think
that it is probably better to leave the function unimplemented at this point.

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

I don't know of a suitable panacea either. In certain libraries, I will
probably make it possible for the user to choose a preimplemented ordering
model or provide one. That approach is probably not useful for the tuple
library.

I have bumbed into situations in which I have wanted multiple ordering models
for a single concept. I think that lexicographical ordering is perhaps the
safest model to provide directly. Other models can be written on top of tuple
using traditional functions.

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

No problem.