|
|
Blitz Devel : |
From: Theodore Papadopoulo (Theodore.Papadopoulo_at_[hidden])
Date: 2004-04-13 13:38:41
cummings_at_[hidden] said:
> 1) There's a code comment in <blitz/array/iter.h> explaining that
> both the prefix and postfix operator++ have been defined to return
> void because the Array iterator type has a lot of state data and is
> relatively expensive to copy. Of course, one can avoid the copy by
> only using the postfix version when it is truly necessary.
Or maybe compilers can avoid copying the data when the result of the
operator is ignored... Never verified that though.
> 2) In general, iterators are an inefficient mechanism for
> multidimensional containers because of the need to check for the end
> of the row in each dimension. That's why it makes a lot of sense to
> write Array expressions and let blitz construct efficient loops for
> you or to create your own functors that will apply some function to
> each element of an Array. This is not an argument for iterators that
> don't comply with the STL, but rather a general argument against
> using iterators with multidimensional containers.
Well, if you want to access all the elements of a multi-dimensionnal
containers an iterator is perfectly OK because there is no check of
boundaries.
Array expressions are OK, but how would you write a QR factorization
with array expressions...
I tend to believe that the only problem with multidimensional containers is
that one does not want a single iterator but rather a variety of
iterators. In my work, I use:
iterator<row>
iterator<column>
iterator<pixel>
and so on... And the result is very pleasing to read. Now of course,
if there is an array expression that can do the same job it has to be
preferred, because it is often clearer and more efficient.
> Blitz users: are there any other issues regarding blitz Array
> iterators?
I did not verify, but I believe that there are some types traits that
need to be defined and maybe also (certainly related) some
iterator_category stuff (this allows stl to select proper algorithms).
Theo.
--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo_at_[hidden] Tel: (33) 04 92 38 76 01
--------------------------------------------------------------------