|
|
Glas :Re: [glas] unallocated fill |
From: Neal Becker (ndbecker2_at_[hidden])
Date: 2005-10-04 05:42:59
On Monday 03 October 2005 4:56 pm, Toon Knapen wrote:
> Neal Becker wrote:
> > It is important to separate allocation and initialization for HPC. Here
> > is what I believe. The default construction should not perform
> > initialization. It looks to me that glas already follows this.
>
> However I'm not sure the current implementation is correct. Currently
> the constructor of the dense_vector just calls the 'allocate(n)' member
> of the allocator. What if an element in the vector will be assigned to
> before fill is being called on the vector? For example following use-case:
>
> <quote>
> glas::dense_vector<double> v(3) ;
> v[0] = 5 ;
> </quote>
>
> So in this scenario an array that can contain 3 double's is allocated.
> However the allocate member function only allocates but does not
> construct any objects in the array (see table 32 in paragraph 20.1.5).
> The second statement in the use-case above however relies on an
> assignment-operator. But the assignment-operator is called on a
> memory-address where no object is constructed yet.
>
> For POD's I guess this will usually work fine but... IIUC uBLAS solves
> this by calling an array-placement-new on the allocate'd array. Is this
> indeed the best way to go ?
>
For PODs and many others this may be OK. I believe the best approach is
1) Don't initialize by default, but
2) Allow initialization as a user-controlled option.
It is not sufficient to use template specialization to handle PODs specially.
For example, std::complex in particularly should be able to bypass
initialization if the user desires.