[boost] Re: review request: container_traits

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-04 11:24:19

Pavol Droba <droba_at_[hidden]> writes:

> On Fri, Oct 03, 2003 at 06:56:02PM -0400, David Abrahams wrote:
>> Pavol Droba <droba_at_[hidden]> writes:
>> 
>> > Given this structure, "new" interface is just a part of layer
>> > 2. This is the presentation layer, but it should be documented
>> > so. Core should be always the layer 1 ( and the "old" interface
>> > ). It is very importatn due to extensibility reasons.
>> 
>> You've got it upside-down, if you care about compile-time efficiency.
>> Using any one of the nested declarations of the "old" interface causes
>> them all to be instantiated.  If you *must* maintain the "old"
>> interface (and I still don't see a good reason for it) it should be
>> built on top of the "new" one.
>> 
>
>>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 ;^)

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

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com