Re: FYI: mx_inlines simplifications

[Jaroslav Hajek]

On Fri, Feb 26, 2010 at 9:48 AM, Jaroslav Hajek <address@hidden> wrote:
> hi all,
>
> based on the previous simplifications of the Array class hierarchy, I
> was finally able to simplify the appliers in mx-inlines:
> http://hg.savannah.gnu.org/hgweb/octave/rev/b47ab50a6aa8
>
> All the appliers are now parametrized directly by value types instead
> of array types, and are accepting & returning generic Arrays.
> The code is now much cleaner and no longer cluttered by the AELEMT
> macro. Also, there should be less distinct instances in total now,
> so maybe the compiler could merge some of them.
>
> Michael, I believe this could solve some of your compilation problems
> with MSVC, because the function template parameter in do_mx_unary_map
> no longer contains dependent names:
>
> template <class R, class X, R fun (X)>
> inline Array<R>
> do_mx_unary_map (const Array<X>& x)
>
> template <class R, class X, R fun (const X&)>
> inline Array<R>
> do_mx_unary_map (const Array<X>& x)
>
> IIRC, according to your tests MSVC handled this simpler case
> correctly. Can you confirm...?
>
> regards
>

Further liboctave cleanup changes:

http://hg.savannah.gnu.org/hgweb/octave/rev/a0728e81ed25
http://hg.savannah.gnu.org/hgweb/octave/rev/96ed7c629bbd
http://hg.savannah.gnu.org/hgweb/octave/rev/532802559f39


Summary:

The mx_*_dup functions are gone from mx-inlines.cc. Those were the
relics of the original mx-inlines implementations where memory was
allocated at the point of the operation instead of at the Array<T>
level. Their use was superseded by the new applier + looper mechanism.

The pointer-acquiring Array constructors (i.e. where a pointer was
allocated through new[] and then given to the Array) are gone.
Therefore, all memory management for Arrays now occurs exclusively
through Array<T>::ArrayRep. The no_ctor_new trick is hence no longer
dangerous (though apparently it worked with all compilers we use).
Further, this opens the way for possibly more advanced memory
management tricks done by Arrays.

Optimizing singleton arrays comes to mind here, because
octave_value_list very often contains just a single entry.

enjoy

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