Re: Moving functions from octave to octave-forge?

[John W. Eaton]

On  9-May-2007, Thomas Treichl wrote:

| Least but not last: The *.mex file porting to *.oct file question? I was told 
| that the *.mex interface functions should become *.oct if they are moved to 
| octave, but I don't like this idea (for me and my use), because as I wrote in 
| the first paragraph I also have the need for this package on MatR13 - so the 
| question for me is: what is the idea resp. the reason behind it for *.mex be 
| ported to *.oct?

David added the following to the FAQ sources today:

  Octave includes an API to the matlab MEX interface. However, as MEX is
  an API to the internals of @sc{Matlab} and the internals of Octave differ to
  @sc{Matlab}, there is necessarily a manipulation of the data to convert from
  a MEX interface to the Octave equivalent. This is notable for all
  complex matrices, where matlab stores complex arrays as real and
  imaginary parts, whereas octave respects the C99/C++ standards of
  co-locating the real/imag parts in memory. Also due to the way matlab
  allows access to the arrays passed through a pointer, the MEX interface
  might require that copies of arrays (even non complex ones). There were
  some serious memory leaks in the MEX API in Octave up to version 2.9.9,
  and version 2.9.10 or later should be used if posible.

so it is generally more efficient to use Octave internals directly
rather than going through the MEX interface.  To have both with a
minimal duplication of code means that you write as much as possible
in in C or C++ in a way that doesn't rely on Octave or Matlab, and
then the .oct and MEX interfaces are just small wrappers around your
code that handle decoding input arguments and packaging output values.

jwe