|
|
Ublas : |
From: Michael Stevens (mail_at_[hidden])
Date: 2005-08-16 11:19:59
Hi Gunter,
On Tuesday 16 August 2005 15:04, 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;
> }
I think this is wrong. Before an element in std::vector is used it is always
initialised by placed copy constructor. This is why this std::vector
constructor with a size takes a default argument of type T with the value
T().
> Why do we need the call of new? (which should actually do nothing ...)
> Why is the "else" part missing?
unbounded_array never uses data_ if size_ is 0. If it does it is a bug!!
> 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.
I think I looked at both GCC and Dinkum (VC) STL and found
'uninitialized_fill_n' was implemented with 'uninitialised_fill' and so the
pointer version seemed the way to go.
All the best,
Michael