I wrote a TCPIP-Socket-Connection with Server and Client in C++, which works quite nice in VisualStudio. Now I want to use the C++ - Client in MATLAB/Simulink through MEX-Files and later in a S-Function.
I found two descriptions about MEX-Files.
C++ MEX File Application Just for C++
C/C++ MEX Files C/C++
Now I am confused, which one would be the one to take. I wrote some easy programms with the second, but always got into problems with datatypes. I think, it is because the given examples and functions are only for C and not for C++.
I appreciate any help! Thank you very much!
The differences:
The C interface described in the second link is much, much older (I used this interface way back in 1998). You can create a MEX-file with this interface and have it run on a large set of different versions of MATLAB. You can use it from C as well as C++ code.
The C++-only interface described in the first link is new in MATLAB R2018a (the C++ classes to manipulate MATLAB arrays were introduced in R2017b, but the ability to write a MEX-file was new in R2018a). MEX-files you write with this interface will not run on prior versions of MATLAB.
Additionally, this interface (finally!) allows for creating shared-data copies, in-place operations, etc. (the stuff we have been asking for for many years, but they didn't want to put into the old C interface because they worried it would be too complex for the average MEX-file writer).
Another change to be aware of:
In R2018a, MATLAB also changed the way that complex arrays are stored in memory. In older versions of MATLAB, the real and imaginary components are stored in separate memory blocks. In R2018a and on, they are stored in the same memory block, in the same fashion as you would likely use in your own code.
This affects MEX-files! If you MEX-file uses complex data, it needs to read and write them in the way that MATLAB stores them. If you run a MEX-file compiled for an older version of MATLAB, or compile a MEX-file using the current default building options in R2018a, a complex array will be copied to the old storage model before being passed to the MEX-file. A new compile option to the mex command, -R2018a, creates MEX-files that pass the data in the new storage model unchanged. But those MEX-files will not be compatible with previous versions of MATLAB.
How to choose?
If you need your MEX-files to run on versions of MATLAB prior to the newest R2018a, use the old C interface, you don't have a choice.
If you want to program in C, use the old C interface.
If you need to use complex data, and don't want to incur the cost of the copy, you need to target R2018a and newer, and R2017b and older, separately. You need to write separate code for these two "platforms". The older versions can only be targeted with the C interface. For the newer versions you can use either interface.
If you appreciate the advantages of modern C++ and would like to take advantage of them, and are targeting only the latest and greatest MATLAB version, then use the new C++ interface. I haven't tried it out yet, but from the documentation it looks to be very well designed.
Related
This question has been bothering me so much for the past couple of days. I was wondering how the standard library works, in terms of functionality. I couldn't find an answer anywhere, even by checking the source code provided by the LLVM compiler which is, for a beginner like me, a really complicated piece of code.
What I'm basically trying to understand here is how does the C++ standard library work. For example let's take the fstream header file which consist of a bunch of functions that help to write to and read from files.
How does it work? Does it use the OS specific API (since the library is cross platform), or what? And, if the standard library can do it, aren't I supposed to be able to mess with some files as well without calling the standard fstream file (which to my experience I can't do)?
I apologize if my questions are unclear since I'm not a native English speaker: feel free to modify this text so as to make it clearer.
Does it use the OS specific API (since the library is cross platform), or what?
At some point, the OS specific API is used. The fstream implementation does not necessarily call an OS function directly. It might use other classes, which call functions inherited from C, etc., but eventually the call chain will lead to an OS call. (Yes, the details are often too complicated for an intermediate programmer to follow. So, as a self-described beginner, your findings are not surprising.)
The library is cross-platform in the sense that on your end (the C++ programmer), the interface is the same regardless of platform. It is not, however, the same library on every platform. Each platform has its own library, exposing the same interface on the C++ side, but making use of different OS calls. (In fact, the same platform might have multiple standard libraries, as the library implementation is provided by your toolchain, not by the standards committee.)
And, if the standard library can do it, aren't I supposed to be able to mess with some files as well without calling the standard fstream file (which to my experience I can't do)?
Yes, you are allowed to. Apparently, you have not been able to yet, but with some practice and guidance you should be able to. Everything in the standard library can be recreated in your own code. The point of the standard library (and most libraries, for that matter) is to save you time, not to enable something that was otherwise unavailable. For example, you don't have to implement a file stream for every program you write; it's in the standard library so you can focus on more interesting aspects of your project.
A compiler is just a program which create executable file or library. You can use the compiler default libraries to gain time or write your own. The default libraries communicate with the os for file operation or memory allocation and provide a simple standard classes to allow the developper to write only one code which work on all target platforms supported by the compiler and the libraries. If you want to write your own you have to write each function for all your target os.
The standard library is cross-platform in a sense that its interface does not change between platforms but its implementation does - or in practical terms - if you only use C++ and its standard library, you can write your code the same way for Linux / Windows / MacOS / Android / Whatever and if you find a C++ compiler for one of those platforms that supports the language features you used, you will be able to compile your code for that platform without rewriting anything.
So while you can use std::vector or std::fstream or any other feature in the library independently of the platform you're writing for and expect the function definitions, type names, etc. to look the same, you cannot expect the executable which you compiled for PC with Windows 10 to run on a phone with Android. You cannot even expect the same executable to run on the same PC but with different system - that is what I mean by "the implementation is different"
There are two main reasons for this difference:
Processors with different architectures (x86-64 and ARM for example) use different instruction sets and as such the C++ source would need to be compiled to a completely different machine code to run properly
Computers with processors of the same architecture which have a different operating system have different ways of dynamically allocating memory, creating files, creating streams, writing to console, creating and scheduling threads etc. - which is part of the system functionality that you use via the standard library
If you really wanted to you could use HeapAlloc() instead of operator new() or CreateThread() instead of stdlib's std::thread but that would force you to both rewrite your program every time you wanted to compile it for something else than Windows and recompile it with the target platform's compiler (and by proxy learn its API). Standard library saves you from that trouble by abstracting away those system calls.
As for the fstream in particular, here is what it uses internally on most PCs nowadays.
Basically, fstream, iostream and printf works based on a kernel function write(). When your code call printf (we use printf as an example), it will finally call write() to let the kernel work on the IO stuff. After that, write() returns and printf returns and your code continues.
So if you really want to know how the printf works internally, you have to read the source code of the Kernel.
But you shouldn't do that for now.
For a beginner, do not try to go deeper when you haven't got a basic cognition about computer. A computer is a project, just like a building. So the right way to learn it is to learn it level by level. First, learning how to use brick and cement to build a building, this is what you should do for now. What you shouldn't do is that you are learning how to build a building and this is your first time to try to use brick, then you are interested in how to produce a brick and start to focus on brick, this is a wrong way to learn IT.
If you are learning C/C++, just learn it. Remember, learn it level by level. For now, knowing how to use printf is enough.
So for the past few hours I've been trying to figure out how to use C++ classes contained in static (or dynamic) libraries from within Lua. I've found several packages, such as LunaFive or SimpleCppBinding, but I seem not to understand how to use them properly. From what I see there's a main function, therefore I guess it's not a library, but an executable which I run and then run the Lua script, which will hook the app and get the class, or something? What I basically want to do is:
create a library containing, for example, a class 'Player' in C++
modify this library to be usable from Lua
somehow use this class and it's methods from within the Lua in the same way as if it would be a Lua class
Is such thing even possible? And if so, could someone explain how such thing can be done?
I'm currently on Windows, but I can do it on Linux as well. On windows I'm using VS, on Linux I'd be using CLion paired with g++. Lua 5.3.
I'm not sure if this is somewhat relevant, but I'm developing a game-mode for FiveM (GTA V multiplayer client). The FiveM comes with a Lua support for scripting by default, but I'd love to use some of the C++ standard libraries and features. Therefore I'd really love to create some libraries for the server in C++, and then use them from within the Lua supplied by FiveM.
Static library: not possible. Your options are: 1. a dynamic library (binary) with some kind of interface accessible by Lua executable (Alien, Lua-specific hooks....) or 2. A custom executable which includes the Lua engine and the C++ stuff with some glue. Your examples with the 'main' function probably are the latter type.
Lua was designed, from the beginning, to be integrated with software written in C and other conventional languages. This duality of languages brings many benefits. Lua is a tiny and simple language, partly because it does not try to do what C is already good for, such as sheer performance, low-level operations, or interface with third-party software.
-Preface
I understand your pain, however Lua simply isn't meant to be used the way you intend, it's actually built to be used the other way around.
The closest thing I can think of to get the result what you want is to have a host C++ application from which you immediately create a lua state and push results of the functions you called from the C++ program into the stack, in return can be used in your Lua script and processed.
If this is something you might be able to adjust to, here is a great starting point
Im trying to understand how a binding (port) to another language works in general, but to help clarify my question I will use the direct example of a project called libsass (A C/C++ implementation of a Sass compiler).
There is another project node-sass
which is Node.js bindings to libsass.
Im assuming this means node-sass is a javascript program which runs on nodejs and nodejs acts as a proxy forwarding instructions to the libsass C++ system level program.
My question is: how does the nodejs intepreter "talk" to the libsass C++ application? - is it using sockets?
sub question: If node-sass exposed an API in the node environment by initialising objects, functions etc that were available to your own node scripts - is this by definition -the "binding"?
The C++ library part is, given that it´s really a library and not some server program, not running by itself and not listening to some socket. If a C++ lib is used in a C++ program, it´s integrated in this programs process too and not running somewhere else.
Many languages have built-in possibilites to access native C language APIs, including Node.js (with C being the de-facto standard for language interoperabilty, eg. because every somewhat important OS consists mainly of C too.). About C++ vs C, it´s not hard to write something in C++ and provide a C interface too.
In such cases, a language binding often is nothing more than something to wrap the complicated native access part in something more easy to use in the target language.
To elaborate a bit further because of the comment:
The OS itself has functions (to be used in C programs) to load C libraries on the fly, get specific functions of them and call them, without the names of lib and functions being known when the C program is compiled (eg. you could make a C program which asks the user to enter a lib name which is then used...).
Independent of that, every language is either made in a way that programs are compiled to "real" programs containing CPU instructions etc., these programs can be executed directly (example: C), or the programs of the language are made is some other format, but a "real" program is needed for every start to help the OS/CPU understanding what should be done (example: Javascript, Java.... You can´t run a program alone without having helper software installed, like a browser or the JRE).
For this second type, the helper software can make use of the lib loading functions of the OS, and if the JS/Java program contains instructions to do so... (and for the first "real" type, a certain level of compatibilty with C libs is automatically given because they use the same binary format (yes, that´s simplified))
I am currently working on a project in C++, and I am actually interested in using Matlab data structures, instead of having to create my own data types (such as matrices, arrays, etc.)
Is there a way to seamlessly use Matlab objects in C++? I don't mind having to run Matlab in the background while my program runs.
EDIT: A starting point is this: http://www.mathworks.co.uk/help/matlab/calling-matlab-engine-from-c-c-and-fortran-programs.html. I will continue reading this.
You can use instead Armadillo C++ maths library; used by NASA, Boeing, Siemens, Deutsche Bank, MIT, CMU, Stanford, etc.
They have good documentation and examples if you are more familiar with MATLAB/OCTAVE
http://arma.sourceforge.net/docs.html#syntax
I would prefer using native C++ library of some sort and not Matlab. This is likely to be faster for both development and execution.
From writing C++ extensions for Matlab I learned one thing: Using Matlab objects in C++ is likely to give you considerable headache.
Matlab data structures are not exposed as C++ classes. Instead, you get pointers that you can manipulate with C-like API functions.
I recommend to use a native C++ library such as Eigen3.
The functionality you are looking at is not really intended to be used as seamless objects. In the past when I have used it I found it much simpler to do the C parts using either native arrays or a third party matrix library and then convert it into a Matlab matrix to return.
Mixing Matlab and C++ is typically done in one of two ways:
Having a C++ program call Matlab to do some specialist processing. This is chiefly useful for rapid development of complex matrix algorithms. You can do this either by calling the full Matlab engine, or by packaging you snippet of Matlab code into a shared library for distribution. (The distributed version packages a distributable copy of the Matlab runtime which is called with your scripts).
Having a Matlab script call a C++ function to do some specialist processing. This is often used to embed C++ implementations of algorithms (such as machine learning models) or to handle specific optimizations.
Both of these use cases have some overhead transferring the data to/from Matlab.
If you are simply looking for some matrix code to use in C++ you would be better off looking into the various C++ matrix libraries, such as the one implemented in Boost.
You can do mixed programming with C++ and Matlab. There are two possible ways:
Call MATLAB Engine directly: Refer to this post for more info. Matlab will run in the background.
Distribute MATLAB into independent shared library: check out here on how to do this (with detail steps and example).
I have some code which I need to code in C++ due to heavy reliance on templates. I want to call this code from MATLAB: basically, I need to pass some parameters to the C++ code, and have the C++ code return a matrix to MATLAB. I have heard this is possible with something called a MEX file which I am still looking into. However I am not sure what is supported in these MEX files. Is all of C++ (e.g. STL and Boost) supported? How difficult is it?
EDIT: I don't need any shared libraries, just header-only stuff like shared_ptr.
Have a look at the MEX-files Guide, especially Section 25–27 for C++.
The basic STL/Boost data structures should work, but threading with Boost could be a problem.
cout will not work as expected in C++, mexPrintf has to be used instead.
It's certainly possible to write C++ MEX files which use STL and boost. In general, you should be able to do anything you please inside a C++ MEX file. The main practical restriction is that MATLAB already ships with a bunch of libraries, so if you're using one of the boost pieces that needs a shared library (some are header-only), you'll need to match the version you compile against with that shipping with MATLAB.
For instance, MATLAB R2009b ships with boost 1.36 (you can tell by looking at the names of the libraries in <matlabroot>/bin/<arch>).
The C++ files are actually compiled by an external compiler. Use mex -setup to select which one (here is a list of supported compilers). Therefore, you shouldn't have too many weird things happen, nor should you be too restricted by what you can do.
I did some MEX stuff last year, and my memory is a bit rusty, but you do need to construct MATLAB arrays using MEX functions. I found the MATLAB documentation adequate, and the whole experience not too painful.
STL is definitely supported. Boost probably yet. The point is as long you have your STL and BOOST deployed on your computer, you should be good to go.