Re: [boost] Re: Beyond Objects [was: Re: Re: review request: container_traits]

From: Mat Marcus (mat-boost_at_[hidden])
Date: 2003-10-06 23:15:19

--On Monday, October 06, 2003 10:18 PM -0400 Brian McNamara 
<lorgon_at_[hidden]> wrote:

[snip]
>
> Of course, the utility of container_traits is thus that you can
>  - take any generic algorithm which works on Containers
>  - rewrite it to access Container attributes via container_traits
>    instead of accessing these attributes directly
>  - now your new algorithm
>     - behaves exactly the same on types which model Container
>     - also now works on some other Container-like types (e.g. array)
>
> Effectively container_traits helps defines a new concept.  We might
> call this new concept ContainerAsViewedViaContainerTraits.  It is a
> super-concept (anti-refinement) of Container, in that
>  - for every type T which models Container
>     - T also models ContainerAsViewedViaContainerTraits
>

Suppose you believe that arrays are useful, and that there is a
necessity to write generic functions and meta-functions that uniformly
apply to some (improved) concept of container. I'm not sure that this
is true but I don't want to argue either way on this one now. But the
rest of this post requires the above assumptions. Then you might argue
that the standard container concept is just wrong. That is to say that
the standard container concepts never should have been defined in
terms of member functions or nested types in the first place. begin()
and end() function templates (restricted via SFINAE, or in a better
world, partially specialized function templates) would be more useful,
as would free (non traits-based) metafunctions (restricted via partial
specialization). Under these assumptions perhaps the member functions
and nested types never should have been part of the public interface
at all. Instead the corresponding free functions should have appeared
in each container's header. Container_traits seems like an effort to
"fix" this state of affairs.

But why try to collect all of the functionality for the different
models of container in one place? If you're going to do this why not
go the whole way?  That is go ahead and define the ImprovedContainer
concept and create a new set of headers such as boost/vector.hpp,
boost/list.hpp, and boost/array.hpp that supply the missing
compile-time and run-time functionality such as free versions of
begin(), end(), iterator<C>::type, etc. and maybe even size() and
find() for each container. Or maybe, following boost::graph, the names
should be vector_as_container.hpp, etc. Those headers would then
supply the functionality needed to allow vector, etc. to model the
improved container concept. In fact you could fix break up and
distribute iterator_traits across these headers too while you were at
it. Users could then write your desired family of generic algorithms
across all of the models of the "improved" container concept.

 - Mat