Re: [boost] Re: review request: container_traits

From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-04 12:34:48

On Sat, Oct 04, 2003 at 12:24:19PM -0400, David Abrahams wrote:

[snip]

> >>From my exprience, a user of container_traits don't usualy use just one part
> > of the interface. Type resolution would have to be replicated for
> > each trait.  This would lead to a quite complicated code. Or will
> > end up with something very similar to the current design. (
> > i.e. common core part used by all traits ).
> 
> It's fine to factor out a common core part, provided that *all* of it
> is actually needed by every other trait.
> 
> > Maybe I'm missing something, so please provide some explanation or
> > example, how to handle this problem in some better way.
> 
> I haven't looked at the implementation of container_traits, so I'm not
> sure how to address that, but this is not a complicated idea.  Would
> you design functions this way?  
> 
>   template <class T>
>   boost::tuple<A,B,C> get_all(T);  // common core
> 
>   template <class T>
>   A get_a(T x) { return get<0>(get_all(x)); }
> 
>   template <class T>
>   B get_b(T x) { return get<1>(get_all(x)); }
> 
>   template <class T>
>   C get_c(T x) { return get<2>(get_all(x)); }
> 
> Only under extraordinary circumstances, IMO.  Maybe you have such
> circumstances here, but that would be pretty extraordinary ;^)
>

Your example is very illustrating :)

Please have a look to container_traits implementation. A good example is
a specialization for build-in array ( like char[] ). 
Chalenge there is to select base type and size of the array. Once this
is performed, all traits are calculated with ease. This specialization 
has the exactly the same structure as the example above. 

For the container_traits the harders part is to resolve the type. Once this
is done, single traits are just a matter of simple forwards. 
So I don't really see the way how the separation of individual traits
would gain some performance.

> > There is another reason, why keep the interface in current state.
> > container_traits follow the same purpose as iterator_traits for the
> > context of containers. It makes sense to keep them in sync. If there
> > were reasons to define iterator_traits in the way the are, the same
> > reasons apply for container traits.
> 
> But there *weren't* reasons to define iterator_traits that way; nobody
> knew any better and until the Boost type traits library came along and
> I insisted on separate traits classes, degenerate multi-valued traits
> were the norm.

I understand, but there is slight distintion between traits from Boost.TypeTrais
library and those declared in iterator_traits and container_traits.

You can see the later two as a description of a given entity. All elemnts together
are related to one entity and they are dependant on each other. Most of the traits
in TypeTraits library are unrealted to each other.

It could be error prone to define for instance value_type and reference_type of the
iterator in two separate traits, because they can easily get out of sync.
In a single trait class, all traits can share the common parts. This could also
simplify writting of such a class.

Regards,

Pavol.