So I'm having the following problem:
I have an MEMS board that runs on FreeRTOS and includes gyro, accelerometer and magnetometer.
I cannot change any existing code (All in C).
Now I have a basic motion detection library written in C++ and I extended this library with some functions (All in C++).
I thought I can just use a C++ compiler and compile everything but I'm getting hundreds of errors.
I found some solution how to use C functions inside C++ but I don't know how to use C++ functions (or libraries) inside C.
Is there a feasible way? Can I somehow wrap all my C++ code in an easy way?
I'm using Keil uvision to compile the code for my embedded system in case that is important.
There are a few differences between C and C++ that may make a compiler stumble over some of the code. See for example the wikipedia page on this topic.
I'd suggest that you split your project into two projects, one being the RTOS and application in C, the other being the motion detection library. Then you have to write a C wrapper around your C++ library API. Here's a good SO post on writing a C wrapper for C++ code.
Then you would have to link your RTOS + application project to your library, which you compiled in your other uVision project.
Related
I need to adapt a file written in Borland C++ Builder 5 to be usable in MS Visual Studio 2022. One of the files heavily utilizes the dir.h library, which, as far as I can tell, is a C library exclusive to Builder. The source files are available, however they have a lot of dependencies and, as I've mentioned, are written in C. I have searched the Internet for a substitute, unfortunately to no avail. Does a similar library exist for C++? Or do I have to re-write the file (which is pretty big) using e.g. std::filesystem?
The functions in dir.h are mapping quite direct to Win32 API calls of fileapi.h. You could use this header for a quick port.
For a modernization, it might be the best idea to re-write the code using std::filesystem. There is hardly any sensible C++ library with such a C-like API.
Well, there are the modernized Embarcadero API-calls in System.SysUtils.hpp, but they are still no modern C++, and they are only available in their ecosystem.
I have a project written in C (on Linux) and now want to use a third-party C ++ library that provides .h and .c source files.
I renamed the .c file to .cpp and then include this library in the C project. However, the following error appears when compiled:
unknown type name ‘class’
Added: The third-party library is here https://github.com/0xmalloc/c-log
The author say it's friendly to both C and C++
There are two options here:
you make your whole project a C++ one - this doesn't mean you need to convert your C code to C++ but rather that you will probably have to touch this and that part of it and also go for a C++ and not C-only compiler
provide wrappers - usually if you write C++ code in C style (no classes etc.) you will only have to do that extern "C" void foo() routine for your C++ functions. However the moment you start working with features that C doesn't support you will have to provide wrappers for your C++ functionality so that it can be exposed to the C part of your application. Such procedure can be from very easy to incredibly complex. For example many modern C/C++ API also provide Python API. In order to do that without having to rewrite everything in Python the authors create wrappers that translate the C/C++ functionality to Python. Depending on how well this is done features of the target language (Python in case we go from C/C++ to Python) can be used to allow better error handling, type checking, readability, native (to the target language) data containers etc.
I do believe that the author of the library misled you since the library is clearly for C++ (the classes in the header are definitely the most obvious thing that just screams C++).
I am considering SWIG as a tool for wrapping certain functionalities of a large library into an SDK. I had some success in wrapping some classes from the C++ library into other languages (e.g. Python, C# and D) but I cannot figure out how to do the same with C++.
In other terms, I would like to let SWIG automatically generate a C++ proxy class (see here) for the C++ target, so that I can expose just a single DLL file and some simplified C++ files that use the DLL. Releasing the underlying C++ library is not feasible. Any ideas?
Edit: as suggested by Jens Munk, there is a Google Summe of Code (GSoC) 2008 branch of Swig that allows to set "c" as the target language. There is also another GSoC 2012 version that allows to set Objective-C target. However, all these versions were not merged into the official release, so one needs to build them from scratch and they contain many annoying issues. As far as I know, there is no good option yet to automatically generate proxy C++ classes via Swig.
Additional material:
Mixing C++ code from different compilers
About support for Objective C target
Google Summer of Code 2008 branch for C++ target
Google Summer of Code 2012 branch for Objective C target
Similar or related question on SO
Blog page of Google Summer of Code 2008
from-different-compilers
I have a C++ dll file that uses a lot of other c++ librarys (IPP, Opencv +++) that I need to load into matlab. How can I do this?
I have tried loadlibrary and mex. The load library does not work.
The mex finds the linux things (platform independent library) and tries to include them. And that does not work.
Does anyone have any good ideas?
loadlibrary should work. I use it all the time to call functions from dlls written in C++ with C wrappers.
What errors are you getting when you try to use loadlibrary?
Make sure that the exported functions of the dll are C functions, not C++ functions. If not, then write C wrappers.
More info on exactly what you are doing when using loadlibrary would be helpful.
As mentioned by others, you should first wrap your C++ library as a C library - mathworks used to advise not to use C++ code directly in mex (dlopening C++ core directly is complicated), maybe it is still true.
Your description is quite unclear, too: what do you mean by "mex finds the linux thing", but that does not work. Saying that it does not work is not helpful: the exact commands and error message are.
You could go for the Java approach (since Matlab runs on a JRE and can access Java objects/methods -- just be aware that the Matlab JRE is not as up-to-date as the latest JRE, the one I'm running uses Java 1.5) and use JNA to access your DLL.
Or, if you wrote the top-level DLL, you could go for the COM/ActiveX approach.
I've had good success architecting the interface to my C++ functions as COM/ActiveX libraries -- you don't have to bother with that .h stuff.
See the External Interfaces guide on COM clients, particularly the part about managing/converting data.
It would be extra work to add the COM/ActiveX layer, but would make your library more portable within the Windows world and probably more easily used in MATLAB.
If you have a lot of function calls to your DLL, the COM/ActiveX approach might be faster (not sure), but otherwise I think the JNA approach would be easier.
I'll preface this by saying I'm a C# programmer who inherited horrible code with no documentation. I have an unmanaged C++ library wrapped with managed code that worked fine in VS2003 with .Net 1.1 Framework. I'm trying to get it upgraded to at least .Net 2.0.
I have the unmanaged C++ library that was compiled with "MSVC 8.x" (thus equivalent to VS 2005, I assume). I've been trying to migrate everything to VS2008 and still have some issues with this library at runtime.
My question is this: should this library work with VS2008? Or should I be developing in VS2005 if the library was compiled with VC8.x?
Any thoughts would be greatly appreciated. Thanks!
It should work, I expect that you are having issues with your marshalling. It is probably stuff that was declared incorrectly for PInvoking that managed to work in .NET 1.1 but not in later versions.
You don't say what sort of problems you are having at run time, nor do you state how you access your library. For example, do you compile your library along with your project? If so, can you turn on unmanaged debugging in your C# project and step into the code you are having trouble with? How are you calling the unmanaged code? Is it through PInvoke, or do you have managed C++ wrappers?
In my experience, the best solution for calling out to a legacy unmanaged library is to add a managed wrapper library for your legacy library written in managed C++. This way you present a managed interface for your library for all .NET languages to consume and you don't have to worry about getting your PInvoke signatures correct.
Your project should look something like this.
C# Application -> Manage C++ Wrapper DLL -> Legacy DLL
It can depend what else the lib relies on. For example, if you are using the STL across the library interfaces then it would be a bad idea to have the library compiled with a different version to the client. However, if the library presents a simple C style function interface then you shouldn't have problems.
If you have the source code for the library then I would recommend trying to port it to VS2008. In general it is much less hassle in the long run to have everything in the same development environment.
How are you wrapping the unmanaged lib ... presumably using managed extensions for C++ if it dates back to VS2003. This is now deprecated and has been replaced with C++/CLI as of VS2005. Whilst the newer compilers support a /clr:oldSyntax switch to still compile the old code there are definitely issues with it. We have old code that will not compile on VS2005(8) using this switch.
--Rob Prouse:
The wrapper uses managed C++, no PInvoke. The wrapper is compiled into a DLL that is then used by another application (as you illustrated).
The legacy code produces graphics objects. When I try to get the handle to an image, I get a null exception instead. The debugger doesn't let me get farther into the code to figure out why. Everything else seems to run ok - the other data objects needed to create the image exist and appear to be correct. (Sorry, I know that is still a pretty vague description.)
--Rob Walker:
I unfortunately do not have the source code.
Not sure about "using the STL across the library interfaces". Does graphics fall under that category?
I was able to get my application to run with using the /clr:oldSyntax switch, but that's where I get the null handles to images. I tried to put in all the modifications so that it would compile with /clr, but then I kept getting link errors that I couldn't resolve. (The linker kept complaining about not being able to find files even though those files were in the folder where it was looking.)