Submission: Fixed-Capacity STL Containers Library (Re:STLcontainer of fixed capacity but

From: rwgk (rwgk_at_[hidden])
Date: 2002-02-08 09:11:26

--- In boost_at_y..., Synge Todo <wistaria_at_i...> wrote:
> I have rewritten my fixed_capacity_vector class to solve the second
> problem (construction of non-POD objects).
> 
>   
http://groups.yahoo.com/group/boost/files/fixed_capacity/fixed_capacit
y_20020208.zip

Wow! First of all, I am impressed by the cleanliness of the
new code and the apparent level of sophistication. (But it
is a bit scary to see how much effort is required to work
around the wrinkles of the language.)

Before looking at your code I did not realize that almost
the entire interface needs to be rewritten to ensure proper
construction and destruction of the contained objects. In
your implementation, the interface in vector_base.hpp is
explicitly duplicated for POD and non-POD types. Is this to
preserve full performance for the POD types?

The specialization for non-POD types has an additional
data member base_, i.e. it consumes more memory than the
POD variant. Couldn't this be avoided by defining a
private function

T* get_base() const {
  return (T*)(alignment * (((size_type)elems_ + max_padding) / 
alignment));
}

One would hope that all compilers are able to optimize this
inline function away.

Finally a general point: the global functions for the
boolean operators (==, !=, <, etc.) follow the example of
std::vector and are implemented as reductions (return a
bool as opposed to a vector of bools). This "buy the whole
shop" approach always struck me as a deliberate limitation.
It is also odd that only the boolean operators are
overloaded by default, but not the arithmetic and logical
operators. Ideas:

1. Provide two types: a plain type that does not overload
   any operators + a regular type with your overloads.
   Then other applications can use the plain type to
   define custom algebras without having to worry
   about incompatible/undesired overloads that are attached
   to the base type.

2. Provide both reducing and element-wise boolean operators,
   and a policy flag to select between the two (or better,
   a three-way option: no operators (i.e. compile-time error),
   reducing, element-wise).

Ralf