Re: issorted & sortrows

[Jaroslav Hajek]

On Wed, Feb 11, 2009 at 7:29 PM, John W. Eaton <address@hidden> wrote:
> On 11-Feb-2009, Jaroslav Hajek wrote:
>
> | Here, this is not so easily possible. The type of
> | octave_sort<T>::compare is bool (*) (T, T), not bool (*) (const T&,
> | const T&), so you'd get a type mismatch. The first form is probably
> | more suitable for simple built-in types, the latter for complex ones.
> | Supporting both would be possible but somewhat complicated.
>
> I don't see why it shouldn't use "const T&".  Doing that shouldn't
> cause trouble for built-in types, and has some advantage for aggregate
> types like Complex or some other class or structure that we may use
> later.  I don't understand why it was ever defined to just use T.
>

Apparently it was David who did it; presumably because he thought it'd
be faster for the simple types. Now, because for the simple types the
comparison is inlined anyway, even this vague reason is probably gone,
so I'm all for changing that to const T&, const T&, presumably
together with a typedef inside octave_sort (as suggested in the
following mail).

If you  want to do it, please go ahead, otherwise I'll do it in near future.

regards

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