Re: Rethinking octave_idx_type

[John W. Eaton]

On 11/28/2016 02:27 PM, Carnë Draug wrote:

> What if instead of changing octave_idx_type, we have Array<T>::size_type
> and Array<T>::difference_type?  These would map nicely to the STL names.
> We have Array<T>::size_type [1] since Octave 4.2 but I will guess this is
> not used outside of core so disruption would be minimal.  We could leave
> octave_idx_type alone and deprecate it while recommending to use this new
> two typedefs.

I agree that these typedefs could be useful.

But if we leave octave_idx_type as 32-bits, we could have overflow 
problems for things like this

  octave_idx_type nel = V.numel ();

when V has more than 2^31 elements.  That means existing code would have 
to be changed to work reliably for large arrays on 64-bit systems even 
when it doesn't call Fortran functions.  That actually seems worse to me 
than just changing the definition of octave_idx_type.

Yes, changing the definition will force people to update their code if 
they want it to work with newer versions of Octave, but it will only 
affect people who are calling Fortran or other libraries where the old 
assumption was that octave_idx_type matched the size of a Fortran INTEGER.

jwe