Re: [ublas] bypass construction interest?

From: Neal Becker (ndbecker2_at_[hidden])
Date: 2007-02-03 11:05:05

Gunter Winkler wrote:

> Hallo, reply below
> 
> On Friday 02 February 2007 12:43, Neal Becker wrote:
>> I don't know.  Here is what I propose:
>>
>>         unbounded_array (size_type size, const ALLOC &a = ALLOC()):
>>             alloc_(a), size_ (size) {
>>             if (size_) {
>>                 data_ = alloc_.allocate (size_);
>>                 if (not boost::has_trivial_constructor<T>::value) { << My
>> Addition // ISSUE some compilers may zero POD here
>> #ifdef BOOST_UBLAS_USEFUL_ARRAY_PLACEMENT_NEW
>>                   // array form fails on some compilers due to size
>>                   cookie,
>> is it standard conforming? new (data_) value_type[size_];
>> #else
>>                   for (pointer d = data_; d != data_ + size_; ++d)
>>                     new (d) value_type;
>> #endif
>>                 }
>>
>>             }
>>
>> How would a special allocator bypass the construction in the above?
> 
> according to Stroustrup §19.4 an allocator has the member functions
> 
> pointer allocate(size_type n, void const *hint=0);
> void deallocate(pointer p, size_type n);
> void construct(pointer p, const T& value);
> void destroy(pointer p);
> 
> thus the line "new (d) value_type;" should be replaced by a.construct(d,
> value_type());
> 
> if the construct() of the allocator does nothing, then we have the
> required behavior.
> 
> TODO: all explicit call to new/delete have to be replaced by either
> alloc.construct(), alloc.destruct() or construct(..) and destruct(..) if
> no allocator is available.
> 
> BTW. std::uninitialized_fill_n(d,n,value_type()); does exactly the same as
> the loop. (see /usr/include/c++/4.1.2/bits/stl_uninitialized.h there is
> even a __uninitialized_fill_n_a(d,n,value,alloc) which really calls
> a.construct(d,x) instead of construct(d,x) );
> 
> Note: The difference between std::fill and std::uninitialized_fill (for
> non-POD types) is that std::fill uses the assignment operator and
> std::uninitialized_fill uses copy construction. (I found this difference
> while using an iterator that stores some references for internal use, the
> copy constructor had to copy references and the index, the assignment only
> assigned the index.)
> 
> Note 2: There are some other allocator examples in
> /usr/include/c++/4.1.2/ext/
> 

OK, here is a try:
(note, this also includes the proposed serialization patch)