Best practices for mex coding

6 visualizzazioni (ultimi 30 giorni)
Jim Hokanson
Jim Hokanson il 26 Ago 2013
Modificato: Matt J il 25 Ago 2017
Hi all,
As I'm starting to include mex code in my code library I find myself unaware of what some best practices may be when developing mex code. For example, how do you organize make scripts? How much interdependency do you allow between given pieces of code given the difficulty in organizing code dependencies. How much difficulty do you encounter in providing cross-system support for mex files? How do you avoid these problems? Within os, how much variability is observed due to other non-os issues such that someone needs to recompile code specifically for their system instead of distributing a singular dll (e.g. .mexw64 file)? How do you handle versioning or distribution of other dynamic or static libraries? How do you like to handle class methods (or significant but related variations in a type of function) given that mex functions are designed around a singular method interface. Do you have any documentation tips you've found useful? Do you shadow your files with m-file implementations?
These questions may be confusing, and I'm sure I am not asking other questions that might be relevant, but the basic question is how to use mex files in a code base without having them be, for lack of a better word, awkward.
Thanks, Jim
  4 Commenti
Jan il 8 Set 2013
Modificato: Jan il 8 Set 2013
Currently your question got 3 votes and only about 110 questions have more votes. I assume posting the different questions in multiple threads might be a very good idea. E.g. I've struggled a lot with compiling MEX files on one platform with different compilers (Borland, OpenWatcom, LCC, MSVC), so asking for cross-system support of MEX files is a very wide field.
Jim Hokanson
Jim Hokanson il 10 Set 2013
Thanks Jan. I was hoping to have one location where people could document different issues that they've come across (sort of like the What's Missing from Matlab question). Perhaps this weekend I'll get some time to make separate questions.

Accedi per commentare.

Risposta accettata

Jan il 27 Ago 2013
Modificato: Jan il 27 Ago 2013
Just some related ideas:
M-file implementations do not shadow the compiled MEX, because the compiled MEX files are preferred. So you can provide M-files to keep the help text of the Mex files, such that help will still be useful.
The code dependencies between MEX files do not differ significantly from M-files, so a general approach for the complete source code is required. A versioning system is fundamental here.
I've written a kind of make procedure as M-file, which sets some macros for the compilation, checks the fingerprints of the files and compiles changes files afterwards.
Unit-tests are required for all function, which compare the results with a list of known answers and checks if wrong input leads to the wanted interruption by an error. Such unit-testing can reveal incompatibilities between Matlab versions and dependencies to the OS and compiler. Providing compiled files is reliable and convenient, but allowing the users to rung their own compiler is useful also.

Più risposte (0)


Scopri di più su Write C Functions Callable from MATLAB (MEX Files) in Help Center e File Exchange

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by