FYI: ArrayN gone

[Jaroslav Hajek]

as a step towards simplifying the liboctave array class hierarchy, I
removed the ArrayN template class:
http://hg.savannah.gnu.org/hgweb/octave/rev/b4fdfee405b5

Rationale:
I don't know the historical purpose of ArrayN, but it surely evolved
into being a mere thin wrapper over Array, adding no useful
functionality besides defining a stream output operator, which can be
easily absorbed into Array.cc (and I'm not sure it's used at all).
Since Array is already multi-dimensional, I think the existence of
ArrayN only added confusion - it certainly confused me when I became a
contributor.
Further, it implied occassional necessity for ugly typecasts - for
instance, Array<T> usually needed to be re-cast to ArrayN<T> in order
to be stored in octave_value.
So I removed the ArrayN layer and replaced its usage by Array
everywhere. This went surprisingly flawlessly; still it uncovered some
hidden bugs in operator handlers where implicit conversion
constructors were silently doing unexpected things, and also some
mismatching types being passed around. Hence the seemingly unrelated
changes.

the ArrayN.h include file still exists but only includes Array.h and
#defines ArrayN to Array. Therefore, a lot of existing code
referencing ArrayN will just silently work with Array instead.
However, I also added a warning for GNU-compatible compilers (this can
be debated), so that users become aware of the obsolete feature. This
layout of things may be debated; for instance, we may make ArrayN
forever a valid alias for Array and print no warning...

MArrayN is the next target (to be merged with MArray). I'm not yet
sure what to do with the Array2 classes.

comments?

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz