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
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.
When MSDN only contains C# examples, and I am trying to code C++, how can I find the names of the required include files? For example, I want to write some C++ code that uses the TextPointer class, how do I find the #include statements that are required?
TextPointer is a .NET class. C++Builder does not support .NET development, which is why its compiler can't find any .NET related C++ header files - they don't exist in C++Builder's runtime libraries.
The only way you can use .NET classes in C++Builder projects is if either:
the .NET classes are COM compatible (ie, have the [ComVisible(true)] attribute), then C++Builder code can create instances of the appropriate COM objects.
you wrap your .NET code in a DLL written in Visual Studio, and have it export a C compatible interface so C++Builder code can then use it.
you use a 3rd party framework, like CrossTalk or Hydra, that allows C++Builder code to host the .NET runtime and use .NET assemblies and types as-is.
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.
I require zlib library for the development of Windows Store app.
Has anyone converted Win32 zlib project to WinRT yet?
Can anyone please describe the steps to convert the existing win32 static lib project to winRT?
Visual C++ is already a supported language for WinRT development, if you wan't to use zlib, just compile it together with your solution. There is nothing that is preventing you from reusing standard ISO C and C++ libraries from within the WinRT, if you are using the C++ language, you might have to expose certain aspects of your library as WinRT Components but only if you need to interface with facilities like XAML or other WinRT languages but that should be a walk in the park. Not something which is tremendously difficult to do.
The whole point of supporting C++ in the WinRT is to allow an existing ecosystem of largely native applications to be ported to the Windows Store. zlib is not an exception. Non-standard ISO C and C++ such as sockets are not supported but there you have alternatives that you can plug-in to, just check that the library you're using has some kind of portability support.
WinRT is very limited with regards to C library functions which are present. What this means is that virtually all cross-platform C libraries are (AFAIK, I'm not a WinRT dev) unusable for that target.
For the case of zlib, there is an alternative: see this question
EDIT: to clarify what I'm saying above, I dug up a list of all CRT functions that are absent for WinRT, which you can find here. As long as zlib or any other C library does not depend on these function calls, you should be able to use the WinRT tools to build that C library. I even found a project file for zlib on winrt by the Ogre team here, not sure how useful it is to you.
You could take a look into this WinRT (Un)Zip component. Its used in production code already.
See the unit tests inside on how to use the component. It compiles on all WinRT architectures including ARM. It has no custom asm for ARM though.
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.)