Boost logo

Boost :

From: Serge Barral (sbarral_at_[hidden])
Date: 2001-03-26 12:42:27


On Mon, 26 Mar 2001 19:06:24 Jeremy Siek wrote:
>
> Potential solution to the problems with option 2).
>
> From operator[](range), return an indexer proxy that collects a list of
> ranges via operator[]. The operator[] for the last dimension returns
> a
> real subarray. If you don't want to specify all the dimensions,
> use the all() shortcut to cover the rest. For examp,e
>

I guess that implementing indexing via comma overloading would require the
same kind of trick, and the subarray style of indexing seems to me more
natural in C++.

On an other topic, I'd be interested to know if the consensus is towards
making an expression template implementation of multidim arrays. I
personnaly believe that dropping ET on the base of portability
considerations would be unfortunate in the long run.

If expression templates are considered, the user should be given the
possibility to take full advantage of it, for example by defining
element-wise functions which could be applied globally to an array without
creating temporaries.
In Blitz it is necessary to use macros. Here is a way which I find more
elegant, using functors (I experimented with it in a modest 1D-array
implementation).

First one defines a STL like functor:

class myfunctor {
public:
    [...]
    double operator() ( double x ) { ... }
    // could even be: template<class T> T operator()( T x ) {..}
    [...]
};

and then a "super-functor" for arrays:

ArrayFunction< myfunctor > myarrayfunction; // could be initialized with
                                            // an instance of "myfunctor"

where ArrayFunction< class T > defines an expression template return type
for operator().

myarrayfunction can then be used with arrays, e.g. : A = 2.0 *
myarrayfunction(B) + 1.0;

This may be done also for binary, ternary,... functions.

I havn't found yet an elegant (macro-free) way to define something like the
Blitz stencils. Any ideas?

           Serge


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk