[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mex API changes for 64bit
From: |
David Bateman |
Subject: |
Re: Mex API changes for 64bit |
Date: |
Sun, 03 Jun 2007 00:00:58 +0200 |
User-agent: |
Thunderbird 1.5.0.7 (X11/20060921) |
David Bateman wrote:
> Index: src/mxarray.h
> ===================================================================
> RCS file: /usr/local/cvsroot/octave/src/mxarray.h,v
> retrieving revision 1.6
> diff -u -r1.6 mxarray.h
> --- src/mxarray.h 8 Mar 2007 22:58:23 -0000 1.6
> +++ src/mxarray.h 2 Jun 2007 21:32:28 -0000
> @@ -81,6 +81,14 @@
> /* typedef Uint16 mxChar; */
> typedef char mxChar;
>
> +/*
> + * FIXME? Mathworks says these should be size_t on 64-bit system and when
> + * mex is used with the -largearraydims flag, but why do that? Its better
> + * to conform to the same indexing as the rest of Octave
> + */
> +typedef octave_idx_type mwSize;
> +typedef octave_idx_type mwIndex;
> +
> #if ! defined (MXARRAY_TYPEDEFS_ONLY)
>
> class octave_value;
>
Except this part of the change is a problem as outside of Octave
octave_idx_type is not defined. I see two solutions. The first is just
to include oct-types.h in mxarray.h, though that might not be acceptable
as it introduces an externally visible dependency on the octave code for
the mex files. The second is to move mxarray.h to mxarray.h.in and have
the typedefs
typedef @OCTAVE_IDX_TYPE@ mwSize;
typedef @OCTAVE_IDX_TYPE@ mwIndex;
then add myarray.h.in to AC_CONFIG_FILES in configure.in. John if you
accept the patch for the mex API changes which of these solutions for
the issue of octave_idx_type do you prefer?
D.
Mex API changes for 64bit, John W. Eaton, 2007/06/02
Re: Mex API changes for 64bit, Christopher Hulbert, 2007/06/02