Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk