关于matlab与c#混合编程的问题

Isn’t it possigble just to introduce a datatypes for MatLab variables? With – for backward compatibility – a generic default type (like Variant in VBA). This will help MathWorks to implement a lot of another features to resolve a lot of my problems like:

1. Auto code completion. Espetially with my own classes – I’d like to see all methods of the corresponding class after typing a variable name followed by a dot.

2. Auto doc generation. Espetially for dependency reports (today it’s impossible to know what class will be passed as a parameter for my function).

3. Methods overloading. Often I’d like to have two methods – just like in your exemple, the same name, the same parameters, but depending of their types, I want to write different function’s bodies. Today I have to write myself a function’s header to determine a case I’m in, and to call one of more specific functions (with strange names instead of the same name – as they do the same thing). 4. Etc., etc.

Joan replied on June 4th, 2011 6:02 pm UTC :2 of 8 Hi,

That sounds really interesting. Any hope to get something similar for Java? Joan

Ben Schmitt replied on June 6th, 2011 1:55 pm UTC :3 of 8

The new feature looks very useful for our applications, I look forward to reading more about it.

I also couldn’t agree more with Alexandre, it would be attractive to have the option of type-explicit m-code, equivalent to VBA’s “Option Explicit”.

Peter Webb replied on June 6th, 2011 5:10 pm UTC :4 of 8 Joan,

We’re definitely thinking about it. But I can’t say that we’ll do it, or if we do, when it might ship. :-)

Peter Webb replied on June 6th, 2011 5:15 pm UTC :5 of 8 Alexandre and Ben,

We’ve been thinking about this for at least a decade, but haven’t come up with a good design yet. It’s a real challenge balancing the ease-of-use and performance trade-offs. For now, the deployment tools are going to limit themselves to managing types at the interface between MATLAB and external execution environments like Microsoft .NET.

owr replied on June 6th, 2011 11:25 pm UTC :6 of 8

Thanks for the example – I am really enjoying the new features in Builder NE. I would love to see some good examples of using the MWObjectArray coupled with .NET External Interfaces to deploy MATLAB functions that return custom C# objects.

Peter Webb replied on June 7th, 2011 3:49 pm UTC :7 of 8

owr,

The type safe APIs will allow you to return custom C# structures from MATLAB functions. (The C# field names have to match the MATLAB field names.) Objects are trickier, because they have methods.

What exactly are you looking for? Automatic generation of a C# object that acts as a proxy for a MATLAB object? Automatic initialization of a C# object from a MATLAB structure? Or something else entirely?

Patrick replied on September 6th, 2011 10:13 am UTC :8 of 8 Loren, Peter,

Good to see that you are improving the Matlab Builder NE.

Conversion of data between Matlab and C# causes a lot of programming and maintenance overhead in our application, so I would love to use the new Type-Safe API.

I’ve tried the Type-Safe API creation to see if we could use it in our application. Some comments:

* Automatic conversion is supported for structs, not objects. Unfortunately this does not lead to a workable solution for us: Structs are not preferred in due to their limitations (eg. being sealed).

* The DeployTool can only generate one TypeSafeAPI per project. We have separated our interface with Matlab into 4 classes. It appears that for this to work we would have to split our interface into 4 seperate assemblies, and 4 TypeSafeAPI assemblies.

Because of the above reasons we will not yet use the TypeSafeAPI functionality. However, using the new Builder NE provides two good additions for us: * the method MWArray.ConvertToNativeTypes() * the MwObjectArray

In the past we have created our own data conversion utilities to maintain readability of our calls to Matlab, and create reusable wrapping code.

These utilities use reflection to map custom .Net objects to MwStructArrays. Due to the above mentioned two additions we were already able to reduce the code for our own conversion utilities by 50%! Hope to see more of these improvements in future releases!

These postings are the author's and don't necessarily represent the opinions of MathWorks.

%% Multiple Inputs and Outputs in Builder NE Type Safe APIs % Guest blogger

% returns with another in an

%