Re: some notes about mex support in Octave

[John W. Eaton]

On  8-Jul-2006, Paul Kienzle wrote:

| Using fortran_vec as I suggested will probably force a copy.  Given
| the above semantics I would be tempted to use data() and cast away
| the const so that simply querying an input argument to a function
| doesn't force a copy.  This may lead to unexpected behaviour, e.g.,
| by mutating existing variables but that is a documented property of
| the mex interface so caveat emptor.

That's all fine except that the documentation gives the green flag to
things like this:

  double *old_data;
  double *new_data;
  int N;
  int M;
  mxArray *some_array = mxCreateDoubleMatrix (0, 0, 0);
  ...
  get values for M, N
  ...
  mxSetM (some_array, M);
  mxSetN (some_array, N);

  old_data = mxGetPr (some_array);
  mxFree (old_data);

  new_data = mxCalloc (sizeof (double), M*N);
  mxSetPr (some_array, new_data);

If the value returned from mxGetPr is really the internal data from a
Matrix object and the user deletes it, then bad things happen.

Or can we get away with this if we ensure that mxFree only deletes
data allocated by the mxMalloc, mxCalloc, and mxRealloc functions and
just ignores everything else so that it will be deleted as before (by
the Matrix class destructor, when there are no more references to it)?

Another tricky case is persistence.  If a mex file makes a value that
comes from Octave persistent, what happens?  I guess we have to grab
an extra reference to the value so that it won't go away while the
persistent flag is set.

So yes, avoiding copies will be much more complex.  That's why I'm
inclined to do the simple but less efficient thing first.

jwe