"Oliver Woodford" wrote in message <firstname.lastname@example.org>... > "Pierre" wrote: > > First, except for the initializing method, one does not necessarily have to write the proxy method WrapperClass/<action> in order to invoke the <action>_mex functions: only declare the <action> method in the class definition and place the mex files in the @WrapperClass directory immediately... you have to implement mexFunction() anyhow, which is another proxy function already and which can take over the part of fetching the C++ object pointer from the Matlab object with mxGetProperty(). I admit, this concerns exclusively code aesthetics but it might slightly improve code maintainability and oversight. > > Another point, which works in favour of the WrapperClass/<action> approach, is that with that approach you can get away with just one mex function. You can then call it with a parameter, e.g. a string, to denote which class function you want to call. That's the way I'm currently doing things, but it is entirely aesthetic, you're right. > > Oliver
You are absolutely right Oliver, I hadn't thought about that approach at all. The single-mex approach is probably the most reasonable one for supposedly 99% of the cases one may want to use the technique proposed herein. Being too much focused on my case, I didn't consider that approach as we've got so much handling of parameter-conversion at transition points, that this single mex would easily bloat up to far over 1500 lines of string comparing if statements, type-casting and array copying (comments excluded) which would be hard to maintain (neither in terms of difficulty nor complexity, but I guess it would become quite error-prone over time).
(Meanwhile I also managed to figure out how to alter properties of handle objects immediately from a mex file: Invoking mxSetProperty() on a const_cast of the concerned prhs[i] seems to work just fine. ;) )