Boost logo

Boost Users :

Subject: Re: [Boost-users] question about multi_array use
From: Jesse Perla (jesseperla_at_[hidden])
Date: 2009-08-10 10:57:06


On Aug 10, 8:30 am, Alle Meije Wink <a.m.w..._at_[hidden]> wrote:
> > On Sat, Aug 8, 2009 at 4:51 PM, Alle Meije Wink<a.m.w..._at_[hidden]> wrote:
> I like the look of boost::Fusion in terms of advanced generic C++
> programming, but in terms of finding a concise description of my image
> template class / class / data type, this may be overshooting the aim a
> bit. Plus I will need to read up on template metaprogramming!

As someone who started using fusion recently, it really is
remarkable. But it is a lot of work if you have never done
metaprogramming before. The "C++ Template Metaprogramming" book is
invaluable, even though it doesn't address fusion directly.

One other (sub-optimal) method might be to fix a maximum number of
dimensions that can be dealt with in the class and use it to
initialize the multi_array:
* When you construct an instance of the class with your "dimensions"
loaded from the file, it could fill in the extents with the proper
extents for the loaded data, and then put in a "1" for the other
extents up to the maximum number of dimensions.
* If you do this in the right order (i.e. put the single extents at
the end rather than the beginning... or vice-versa depending on your
storage ordering...) you might not have much of a performance hit
since the strides might run through your real dimensions directly.
* You can always address the multi_array indirectly by passing in a
container of std::size_t indices, which you could pad with the
appropriate number of "1"s depending on how many dimensions you are
dealing with.
* Or last, you could start recursively getting iterators from the
multi_array to drop the dimension as many times as you have useless
dimensions.
* This all sounds like a pain, but it might not be that bad.


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net