Policy-based vector? [was: Submission: Fixed-Capacity STL Containers Library]

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-02-06 12:36:48

At 06:50 AM 2/6/2002, vesa_karvonen wrote:

 >--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
 >> How many "design directions" are there for vectors?  (In the
 >> terminology I think in the questions becomes something like "How
 >> many features are there in the feature model?")
 >
 >The amount of distinct configurations is measured in the millions.
 >
 >Of course, I'm talking about a slightly different thing. Namely the
 >concept of a sequence container.

Yes, I was thinking more in terms of the traditional std::vector. Trying to 
see if the mainstream design space was large enough to warrant a policy 
based approach.

 >Some additional directions:
 >- error checking & reporting (these are two different things)
 >- thread related issues
 >- iterator in/validation
 >- interface & performance issues (which operations to provide in
 >specified complexity bounds)
 >
 >I can hardly think of a situation in which a standard container would
 >not be sub-optimal.

Sure, but how sub-optimal?  The difference in timings between dynamic/fixed 
Capacity were certainly enough to be interesting.  They are greater than 
the typical difference between hash_map and a regular map, for example.

Some of the other directions you mention also give an initial impression of 
being significant enough to make a policy based approach attractive.

What always bothers me are the "optimizations" that disappear if something 
changes slightly.  Like merely a new release of the compiler.  But 
interface or semantic policy differences don't fall in that category.  They 
can bring great benefits if there is a real need.

Andrei's argument for a single policy based vector rather than several 
vector classes is a powerful one.  Actually seeing a proposal for what 
those policies might achieve would make it easier to form a final 
opinion.  Policies that no one ever uses just get in the way.  But policies 
that are really useful become a killer argument, IMO.

--Beman