Boost logo

Boost :

From: Giovanni Bavestrelli (gbavestrelli_at_[hidden])
Date: 2000-12-04 17:37:48

--- In boost_at_[hidden], Gary Powell <Gary.Powell_at_s...> wrote:
> > Yes, I'm very familiar with PETE, however I'd vote against using
> > expression templates (ET) for the boost multi-dim array library.
> > reason is that there are already good ET-based array libraries:
Pooma and
> > Blitz. However, there is a need out there for a more portable,
> > and faster to compiler array library. I think the boost array
> > should fill this need.
> >

I still don't know much about Blitz (though I downloaded it) but I
did investigate POOMA, and I discussed it in the article, on the web
at (I think it should be moved to the Archive section by
now, under December 2000). It's really a totally different thing.
Compared to my array it's huge, limited to 7 dimensions, limited to
holding numeric types, does not use operator [] etc. They are meant
for totally different uses.
> Ok, what if we did not implement the binary operator's "+", "-
", "*", and
> "/" returning temporaries because of their inefficiency. Instead do
just the
> "+=", "-=", "*=", and "/="?

I would not even implement those, to start off with, at least. I
would see my multidimensional Array as being similar to std::vector,
but for multidimensional arrays, and so being able to hold elements
of any type, also types that have nothing to do with numbers.
std::vector does not have anything specific to numeric handling,
though std::valarray does. Similarly, we could define a N-dimensional
array with numeric support separately from a generic N-dimensional
Array, and we could start with the latter as it is simpler, smaller
and more generic.

> > P.S. PETE uses partial specialization all over the place, and
> > can not be used with the world's most popular wanna-be C++
> >
> Dang! It's going to be at least 2 years before this gets fixed. Any
> of not supporting this set of users? Or is this really a
> class? and you recommend that everyone else use MT, or Pooma?

Sorry to say it, but my Array also uses partial specialization. I had
to use a hack to make it work with Visual C++, and the hack works
fine (up to a certain point) but is not standard C++ and I don't know
how fast the VC++ implementation is. The problem with the VC++
implementation is that the SubArray/RefArray classes are nested
inside the Array class, to avoid partial specialization, and if I
have 3D array so defined:

Array<int,3> A3;

the type of one of its SubArrays in the standard implementation is:


while with the VC++ version the type of its SubArrays is:


This is rather ugly, as with VC++ a bidimensional SubArray inside a 4
dimensional array of ints has a different type from a bidimensional
SubArray inside a 3 dimensional array of ints (though the two types
behave identically). This is the main problem I see with the VC++
version, which for the rest works fine (speed aside, I haven't tested
it much). But still, I think my array is different from MTL and POOMA
mainly for its size, generality and simplicity, and I agree with
Beman who wrote:

>* Work extra hard (and document decisions in the docs rationale) to
>feature bloat. Don't let specification creep make a mockery of
the "lite" objective.

Giovanni Bavestrelli

Boost list run by bdawes at, gregod at, cpdaniel at, john at