Boost logo

Boost :

From: Ross Smith (r-smith_at_[hidden])
Date: 2002-03-08 17:44:51


Peter Dimov wrote:
>
> No. One way to solve it (that I see) is
>
> template<class F> vector::vector(size_type n, F f);
>
> that will allocate memory and use f(this->_Ptr, n) to initialize it.
>
> [ snip ]
>
> As I see it, _someone_ has to initialize the vector. The problem is when we
> have a library function that will initialize an array of doubles.
> Constructing a vector inits to zero, then that library function inits to the
> right values, hence the double init problem.
>
> Passing the function to the vector constructor solves the problem - and
> leaves the vector initialized so that its other methods work after
> construction, as is the case now.
>
> Is there another instance of the "expensive init" problem that I'm missing?

Initialisation in a single function isn't always desirable.
Initialisation in the same order as the memory layout isn't always
desirable. Initialisation at construction time isn't always desirable.

The situation that prompted me to write my own uninitialised-vector
template was an image processing application in which the vector was the
underlying storage for a two-dimensional array of pixels. In some cases,
the image would be built up later from several rectangular patches. This
meant that any initialisation at construction time was wasted, and also
that I didn't necessarily know in advance in what order the vector
elements would need to be initialised. And because of the size of the
images (>100MB in some cases), premature initialisation could be quite
expensive.

_No_ solution involving initialisation at vector construction time could
have solved this one; initialise-on-demand was vital.

-- 
Ross Smith ...................................... Auckland, New Zealand
r-smith_at_[hidden] ....................................................
  "We need a new cosmology. New gods. New sacraments. Another drink."
                                                       -- Patti Smith

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