$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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. 
The
> > 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, 
simpler,
> > and faster to compiler array library. I think the boost array 
library
> > 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 www.cuj.com (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 
hence
> >  can not be used with the world's most popular wanna-be C++ 
compiler.
> > 
> Dang! It's going to be at least 2 years before this gets fixed. Any 
chance
> of not supporting this set of users? Or is this really a 
boost::MSVCMatrix
> 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:
RefArray<int,2> 
while with the VC++ version the type of its SubArrays is:
Array<int,3>::RefArray<2> 
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 
prevent 
>feature bloat. Don't let specification creep make a mockery of 
the "lite"  objective.
Giovanni Bavestrelli