From: jhrwalter (walter_at_[hidden])
Date: 2001-12-08 07:18:09
--- In boost_at_y..., Toon Knapen <toon.knapen_at_s...> wrote:
> jhrwalter wrote:
[snip]
> > Do we really need reserve()? IMO the allocation behaviour of
resize()
> > is a quality of implementation issue, especially since resize()
is a
> > method of the proxy concept. If we intend to make it's behaviour
> > transparent, we'd have to introduce capacity() first.
>
>
> I find this really necessary (there's also a good reason why they
have
> capacity and size in std::vector). Everytime you shrink the vector
or
> matrix (i.e. resize(x) with x < size() ), you are going to delete[]
the
> old data and new[] another array. This is very time consuming.
> I would suggest to allign totally with what std::vector does : you
can
> resize without reallocation (if the capacity is large enough) and
you
> can easily shrink the capacity by copying to a smaller vector.
Ok, I was too lazy last time ;-). I should have mentioned that
constructors and resize members of vector and matrix containers
usually only allocate the space to store data, they do not initialize
their elements (should they?). In this sense they behave like
std::vector's reserve().
I think, if we differentiate (allocated) capacity and (actual used)
size, we should be able to achieve your requirement without
introducing reserve().
> > OTOH capacity() won't be generic.
>
> please elaborate.
>
Matrix containers can be organized in different ways: as a container
of containers (e.g. vector<vector<> >) or as an mapping to an 1-D
storage container (e.g. matrix (i, j) == vector (i * size2 + j)).
In the former case we should define capacity1()/capacity2() to return
the number of allocated rows/columns, in the latter we should define
capacity() to return the number of allocated elements in the 1-D
storage container.
> > BTW, do we need to consider std::allocator?
> In the long term : yes. But no allocater can be as smart as what
you
>
> can do with capacity() and resize(). So the allocator is not a
solution
>
> to the above problem.
> An allocator would be nice e.g. to optimise allocation of many
small
> matrices.
I agree to postpone.
Regards
Joerg