Is there a C++ "port" of .NET library, in the sense that the library class and methods correspond? At least some of them? Like System.Xml, System.Net?
You can have a mixed code solution whic contains pure c++ code and c++ cli code. Assuming of course that you are interested only in windows os.
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.
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 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.)