From: Neal Becker (ndbecker2_at_[hidden])
Date: 2007-02-02 06:43:40
Gunter Winkler wrote:
> On Thursday 01 February 2007 19:59, Neal Becker wrote:
>> I am (once again) looking into avoiding unnecessary construction of
>> vector/matrix. In particular, this is interesting for std::complex,
>> since (unfortunately) it's constructor is non-trivial.
>>
>> I am looking into the following. In storage.hpp, use
>>
>> boost::has_trivial_constructor
>>
>> to dispatch.
>
> Can this be done via a special Allocator? I think the least intrusive
> method should be to have an allocator that initilizes the new storage and
> to have one that does not do this. (The change would be to call
> alloc.contruct(..) instead of explicite use value_type(). Right?)
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?
>> vector (size, init_value)
>> matrix (size1, size2, init_value)
>
> The same can be done by using the copy constructor:
>
> vector<double> v = scalar_vector<double>(size, value);
>
> IMO the default behaviour of 'no construction' should be enough.
>
True, although I personally prefer the extra constructor, since it is only a small
addition and consistent with familiar stl container behavior.