Boost logo

Ublas :

From: Gunter Winkler (guwi17_at_[hidden])
Date: 2007-02-02 07:50:16

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
> // 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,

if the construct() of the allocator does nothing, then we have the required

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/