|
|
Ublas : |
From: Neal Becker (ndbecker2_at_[hidden])
Date: 2005-08-16 08:15:49
Gunter Winkler wrote:
> On Tuesday 16 August 2005 13:02, Neal Becker wrote:
>> I need a way to construct large vectors of complex numbers. I want to
>> bypass the wasteful default construction of the complex elements. What
>> would be the preferred way to do this using ublas? Has anyone already
>> done this?
>
> The short answer:
> You can either provide another alloctor class or another array class.
>
> The long answer:
>
> usually you use the type
> vector< T, unbounded_array<T, std::allocator<T> >
>
> where T is the data type. You can provide any allocator. The current
> implementation is (see storage.hpp)
>
> explicit BOOST_UBLAS_INLINE
> unbounded_array (size_type size, const ALLOC &a = ALLOC()):
> alloc_(a), size_ (size) {
> if (size_) {
> data_ = alloc_.allocate (size_);
> // 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
> }
> }
>
> IMHO this does not correctly use the allocator. Looking at std::vector the
> constructor should read:
>
> explicit BOOST_UBLAS_INLINE
> unbounded_array (size_type size, const ALLOC &a = ALLOC()):
> alloc_(a), size_ (size) {
> if (size_) {
> data_ = alloc_.allocate (size_);
> }
> else
> data_ = 0;
> }
>
> Why do we need the call of new? (which should actually do nothing ...)
> Why is the "else" part missing?
>
> another remark:
> Why do we not use std::uninitialized_fill_n(data_, size_, init) for the
> initializing contructor? This could (possibly) be better optimized than
> the iterator version.
>
>
IIUC, I can provide my own allocator, but the call to new is going to call
the constructor, correct?