Re: [boost] Submission: Fixed-Capacity STL Containers Library (Re: STLcontainer of fixed capacity but va

From: Synge Todo (wistaria_at_[hidden])
Date: 2002-02-06 06:40:01

Dear Alisdair,

From: "Alisdair Meredith" <alisdair.meredith_at_[hidden]>
Date: Wed, 06 Feb 2002 09:48:12 +0000
> I believe both calls to insert can fail on copy-constructors, and
> leave you with a modified container [so breaking the exception
> guarantees]
>
> Not sure how to fix this [or if it is fixable] but it should at
> least be documented.

You are right.  I have indicated this breaking of exception-safty in
the document:

[from index.html]

  Recommendation

  Use a standard STL container (std::vector, etc) as long as
  possible. The standard STL containers are (expected to be)
  well-tested, exception-safe, and efficient enough for most
  applications. Use a fixed-capacity container, if and only if the
  efficiency or the space of the container is critical for your
  application, and you are sure of the maximum number of elements.

But I agree that it's better to write it more explicitly.

> I expect [no timing tests done] that this also means swapping
> fixed_vectors should be significantly slower than std::vectors.
> Given the relative infrequency of swapping the containers, the
> tradoff is likely worthwhile, but again worth noting [after
> measurements!]

As for this point, I have written it clearly in the document.  I think
this overhead is inevitable.

[again from index.html]

  Complexity

  All the member functions should be the same complexity as those of
  the corresponding standard containers, except that the swap() member
  function as well as the global swap() function has a linear
  complexity (not a constant time) unlike the standard ones.

Synge Todo
wistaria_at_[hidden]