Re: [ublas] revised patch to control initialization of vector

From: Michael Stevens (mail_at_[hidden])
Date: 2005-08-18 10:53:10

On Thursday 18 August 2005 13:04, Neal Becker wrote:
> Gunter Winkler wrote:
> > On Wednesday 17 August 2005 23:41, Neal Becker wrote:
> >> Here is a revised patch.  I think I prefer this method to control
> >> initialization (pass an argument to vector constructor)
> >
> > the line
> >         data_ (size, std::allocator<T>(), doinit) {
> > of the vector contructor look dangerous. It should read
> > data_ (size, typename array_type::allocator_type(), doinit) {
>
> Yes, thanks.  Actually, though, it looks to me that vector.hpp doesn't
> properly support allocators?  It seems to only use the std:: default.
> Another reason to add my patch.

It not as bad as that. The uBLAS Storage types have the full STL allocator 
interface. This includes an allocator instance in the constructors.

At present the uBLAS Container types only support allocators by the type of 
the Storage template parameter. There is no provision in the constructor to 
parameterise the allocation.

This is not as restrictive as it seems as the ISO standard specifies in 
20.1.5:

Implementations of containers described in this International Standard are 
permitted to assume that their
Allocator template parameter meets the following two additional requirements 
beyond those in Table 32.
— All instances of a given allocator type are required to be interchangeable 
and always compare equal to
each other.
— The typedef members pointer, const_pointer, size_type, and difference_type 
are
required to be T*,T const*, size_t, and ptrdiff_t, respectively.

We have 3 options
a) Leave uBLAS Containers as they are and document the restriction
b) Extend the Containers so their constructors take an allocator instance as a 
parameter
c) Extend the Containers so their constructors take an instance of the Storage 
type as a parameter

b) c) Are hard. You must sure that all occurrences were Storage types are 
constructed pass on the parameter. This makes the code very hard to maintain 
without an appropriate test suite that checks for any regressions.

What do people feel?

Michael