[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Making sort a method of Array<T>, Sparse<T> and octave_value classes
From: |
David Bateman |
Subject: |
Re: Making sort a method of Array<T>, Sparse<T> and octave_value classes |
Date: |
Thu, 31 Jan 2008 10:33:06 +0100 |
User-agent: |
Thunderbird 2.0.0.6 (X11/20070914) |
John W. Eaton wrote:
> On 31-Jan-2008, David Bateman wrote:
>
> | I see no reason not to do, but there are many ways to do it, and maybe
> | you don't agree with the one I picked.. Since if this patch is accepted
> | it'll be the model for how the others are converted to behave in a
> | similar manner it makes sense to get the way its implemented to be the
> | closest to what you'd like to see.
>
> It seems OK to me.
>
> One thing I don't quite get is the purpose of NO_INSTANTIATE_ARRAY_SORT.
>
The Array<idx_vector> was giving me problems without it as the
Array<idx_vector>::sort method of Array<T>::sort was instantiated and
that had a default sort based on the > operator that is not defined for
Array<idx_vector>. Maybe there is a better way than this to avoid the
instantiation.
> | Note that I have a new version of this patch that adds tests for cell
> | string arrays and int -> octave_idx_type changes in oct-sort.{cc,h} for
> | 64-bit platforms, though that doesn't change the basic idea of the patch
> | and so I won't send it to the list to avoid mail bombing everyone.
>
> If you think it is complete (or close), then please check it in.
>
Ok, will do later tonight.
D.
> Thanks,
>
> jwe
>
>
--
David Bateman address@hidden
Motorola Labs - Paris +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin +33 6 72 01 06 33 (Mob)
91193 Gif-Sur-Yvette FRANCE +33 1 69 35 77 01 (Fax)
The information contained in this communication has been classified as:
[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary