[boost] Re: container traits (was: Pre-submission: container algorithms)

From: Beman Dawes (beman_at_[hidden])
Date: 1999-07-07 07:15:27

At 11:19 AM 7/4/99 +0200, Nicolai Josuttis wrote:

>I don't like that the programmer still has to 
>know whether he has to use erase_sequence() or erase_node_based().
>
>A long time ago I discussed with Matt a more general approach.
>The introdution of container_traits.
>With container_traits we could implement algorithms and functions
>that automatically use the best way to process the operation
>(just the way distance() and advance() operate for iterators).
>So, the programmer has just to say what he want without
>thinking about it (OK, a programmer should better know what he does,
but ...)
>E.g. we could define container categories such as
> sequence_container, associative_container, node_based_container
>or just the name of the container (vector_container etc.).
> 
>Unfortunately, this is an extension inside the container
>classes, so we caan't ship it as separate extension.
>But it would be worth it to force this concept.
>Let's make a concept for container_traits that would fit
>all meeds best and force implementors to implement it.
>Then we could ship a lot nice and easy interfaces for the STL.

Let's assume a container traits extension would be useful.  Here is a
possible sequence of steps that could make it happen:

   *  Someone [Nico?] writes a specification, including a sample
implementation, which is posted on www.boost.org.  The sample
implementation might be code that has to be inserted in actual
Standard Library container implementations.  Messy, but the only way
to get started, I think.
   *  Useful functions and classes are posted, initially on
www.boost.org, and eventually elsewhere, that rely on these container
traits and can't be otherwise implemented.
   *  Enough programmers start using these extensions, or asking
vendors for them, that vendors start including them in Standard
Library implementations.
   *  In due time, the standards committee reacts, and adds the
extensions in a TC or to the next standard. (Remember too than time
on a standards committee is measured in years!)

Is this likely to happen?  Only if the functions and classes that
rely on container traits are fairly compelling.  There has to be
enough real advantage to make programmers, library vendors, and
standards committee members willing to accept an extension.  Even a
simple extension is a great deal of work (and cost) for some of these
people, so it won't get backing unless it solves some real problems
that people really care about.

An extension probably will not happen if the only advantage is that a
few of Vanentin's functions can combine the ..._sequence and
...node_based variations.  But it might happen if the list of what
becomes possible grows longer.

--Beman

 

------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com - Simplifying group communications