Re: Rethinking octave_idx_type

[Mike Miller]

On Fri, Nov 25, 2016 at 12:21:47 -0500, John W. Eaton wrote:
> Currently we define octave_idx_type to be the same as the integer type used
> by BLAS, LAPACK, and other functions that have a "Fortran" interface.  By
> default, this means 32-bit integers even on 64-bit systems and arrays are
> limited to less than 2^31 elements.  This affects all of Octave, even if you
> don't actually want to pass large arrays to the functions that actually have
> these size limits.
> 
> Instead, it seems that we could define octave_idx_type to be ssize_t (or
> ptrdiff_t, I think they are equivalent in practice).  Then things like
> fread, fwrite, or simple element-by-element array operations that don't
> require BLAS or LAPACK functions could work on larger arrays.
> 
> Then we would also define something like fortran_integer_type for the
> Fortran-style function interfaces and check array sizes and limits when we
> actually call the Fortran-style functions.
> 
> Does anyone see a reason NOT to do this?

I think this is a good idea, isolate the integer indexing problem down
to just the interfaces that it affects.

Do you have a reason to prefer a signed type rather than an unsigned
size_t? Using a size_t would make Array<T> more compatible with STL
container definitions.

I see this as a way of making our API more standards compatible and
requiring fewer custom types. The octave_idx_type type may not even be
needed at some point.

-- 
mike