From: Joerg Walter (jhr.walter_at_[hidden])
Date: 2003-10-30 03:22:51
> >I've recently started to write ublas adaptors for multi_array and its
> >A couple of observations/questions:
> >- it probably would be a bit easier to adapt multi_array if it would be
> >default constructible
> Yes. As it happens, I added support for a default-constructible
> multi_array at the same time as I added the resize operation. Resizing
> and default construction seemed tied together.
> >- I don't like the necessity very much to 'typedef' multi_array's range
> >- how does one distinguish multi_arrays from multi_array_views
> Currently there is no mechanism for doing so. When is this
> functionality useful?
Multi_array's copy constructor performs a deep copy. So to hold a reference
to it in ublas' expression template machinery I'll probably have to use some
kind of reference_wrapper (I believe multi_array_ref is the way to go). This
indirection shouldn't be necessary if we're going to adapt a
multi_array_view (but it probably won't hurt too much).
I'll check this.
> >And one from Kresimir Fresl:
> >- how does one distinguish C storage and Fortran storage layout
> Since the storage layout is not part of an array's type,
It is for ublas' containers.
> you cannot
> distinguish the two generically (assuming that by generically you mean
> "at compile time").
> The multi_array has a storage_order member function
> that returns the storage order object. This can be used at runtime to
> determine the storage order of an array, though it is expressed in a
> more general form than C or Fortran storage order.
OK, so the user probably has to explicitely specify row major or column
major order when describing the type of a multi_array::matrix_adaptor (and
this could differ from multi_array's storage order). Don't know if that's
> Hope this helps,
Thanks very much,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk