I am working with C++/CLI for C Library. I explored in the net about it. I got several links about it.
Mixed mode C++/CLI performance considerations - best practices
I am developing a C++/CLI DLL which will wrap a C static library.
There was one suggestion that I really wanted to discuss here is "One should not mix up managed and unmanaged C++ code in wrapper". I don't understand meaning of it.
The managed DLL will, of course, contain managed C++ code and unmanaged C++ code.
The purpose of the wrapper is to translate calls from the static library to managed code DLL.
Please clear my doubts - I wanted comments on this.
If you have a regular C++ library (non-CLI), you should avoid turning on the 'CLI' compilation option for that library, for performance reasons.
Instead it is good practice to create a library that just has your wrapper classes in it. This library will of course be C++/CLI, and will create an assembly that can be referenced by regular .Net libraries.
So that's probably what the advice would be talking about - create a wrapper library for your CLI wrappers
-- addendum for the updated question
A managed C++/CLI class should not contain unmanaged code because it /cannot/ contain many types of unmanaged code.
For example, a C++/CLI class cannot have any unmanaged member variables that are not references or pointers. This is because the .Net runtime garbage collector may decide to put the object somewhere else in memory at any time (this is the reason you need to pin memory etc.). If the GC decides to move your native C++ objects to some other place in memory, this will potentially invalidate any pointers you have to that object. This is obviously bad.
C++/CLI is a great language. If you use it, however, you should either decide to write pure .Net code, or you should use it as an interface between native C++ and .Net. Having mixed memory models in the same class just confuses things.
Related
I have a C++ *.h file with three classes in it. The header file is for accessing a DLL. I have almost no C++ knowledge. However, I seem to recall from somewhere that you can't convert a *.h file to a Delphi unit that has classes in it. Is this true?
If it isn't true, and classes in header files aren't a problem, what is the general approach to converting the classes to Delphi?
C++ classes, just like Delphi classes, are not designed for binary interop.
A Delphi class can only be exported for consumption by other Delphi code, and then only in a package, and only when runtime packages are in use, and only when all modules use the same version of Delphi. In a similar vein, C++ classes can only be imported from a DLL by code compiled with the same tool chain that compiled the DLL.
So, it is not possible for your Delphi code to consume this DLL. As I see it you have the following options:
Persuade the supplier of the DLL to provide an interop friendly interface to the library. For instance, a plain functional C style interface, or a COM interface.
Write an adapter in C++, using the same compiler that was used to build the DLL. That would involve you importing the classes into your wrapper and exposing them to your Delphi code in an interop friendly manner. Again, plain C style interface or COM are the obvious choices.
In the sense of allowing you to use the DLL from Delphi code? Yeah, good luck with that. You know how you can't use Delphi classes in a DLL unless the client code is written in the same version of Delphi and even then it's usually a bad idea due to shared memory management gotchas? C++ poses exactly the same problem, only exponentially worse because there's no standardized ABI and there's all sorts of C++-language screwed-uppedness making problems for you.
The only real way to make it work reliably is with an interface that uses a standard ABI. If you have the source, try making a C interface that wraps the C++ interface. If not, ask the person who wrote the DLL to provide a C interface, and ask whoever made the decision to use this DLL why you're using a 3rd party library with no source available. :P
As commented in a previous answer the solution is using SWIG in order to generate the pascal binding. I started the development of the SWIG's pascal module but I had not time to complete it. Basically it works but it lacks all the test cases to be integrated into SWIG.
I used it in my personal projects and I was able to import complex library as GDAL.
I have a need to create a C++ non-dotnet DLL that will be called and used by a VB.net application. I am trying to determine the type of DLL to create. The DLL will contain some classes, variables, and functions that I will be writing. I understand that there are three types of a DLL that can be created: 1) Regular DLL - Statically Linked to MFC, 2) Regular DLL - Dynamically Linked to MFC, and 3) DLL that uses the Standard Windows Libraries, non-MFC.
My question is, which would be the best to use, one that is linked to the MFC, or one that uses the standard windows libraries? Can someone make a suggestion and explain the differences between MFC and the standard libraries?
Thanks!
Gary
Microsoft Foundation Classes (MFC) are a relatively thin C++ wrapper around the Win32 API, with an emphasis on UI coding. You won't need to statically or dynamically link MFC to your DLL unless you are making use of MFC facilities such as its container classes or trying to display UI written with MFC in your C++ DLL. These are unlikely scenarios.
People have been calling unmanaged code from VB.NET since .NET began. There's a whole wiki available on the subject here at http://www.pinvoke.net/ and there's a useful walkthrough on CodeProject, http://www.codeproject.com/Articles/6243/Step-by-Step-Calling-C-DLLs-from-VC-and-VB-Part-2 as well. I recommend starting there.
It's a little more complex, but you can also write managed code in C++ by using C++/CLI that can be referenced just like any other managed code assembly instead of using platform invoke. You can use it to create VB-callable managed interfaces that call unmanaged, plain old C++ code. There's an introduction to C++/CLI on MSDN at http://msdn.microsoft.com/en-us/library/ms379617(v=vs.80).aspx and a quick example of using it as a shim for unmanaged C++ in this MSDN Blog entry: http://blogs.msdn.com/b/junfeng/archive/2006/05/20/599434.aspx
Hi we have a c++ project (library) which has to exposed to .net languages or may be other languages (old vb for example but this is not very important). Two options are write COM wrapper for the project or managed c++ wrapper. Which one to choose?
One great advantage, for example, of using manged c++ is using .net collections classes to pass as a parameters instead of enormous complexity of collections in COM.
The term "COM wrapper" doesn't make much sense. If want to create a COM class, there's no reason why you should first create a vanilla C++ class and then create a COM class that wraps it and mimics it. That's one advantage of COM over managed C++: in managed C++, you DO have to create a vanilla C++ class (for unmanaged clients, unless you don't have any) and a managed wrapper class for it (for managed clients).
In my opinion, the deciding factors for when you should use COM or managed C++ for interop are easy:
Use COM if you want to create a completely new unmanaged class (not a wrapper) that can be consumed by clients in any language.
Use managed C++ if want to create a completely new class (not a wrapper) in which you mix a lot of managed and unmanaged code.
So you see, the word "wrapper" shouldn't come up anywhere in your design. Wrappers suck :)
If you're COM collections are enormously complex, you may want to rethink how you approach COM collection management. Totally different issue there, but that being said...
Your mention of old-VB not being very important is more critical to your answer than you may think. Old VB doesn't speak .NET, but it does speak COM very well. If you foresee having to go that road, that is a major push to the COM side.
I'm not a fan-per'se of managed C++ only because it is about the most non-portable, hard-to-manage, hard to read dialect of the language you'll likely ever encounter. However, if the core code in your library is simple enough, you could probably get it up and running in managed C++ with reasonable effort. The more dynamic the library is, the harder it will be to port to .NET management. However...
Once it is there, a COM wrapper can get you back to your COM clients like legacy VB without too many problems provided you took wise choices when doing the port and kept things easily wrappable along the way.
Thats about the most round-about way I can say (with great pain) managed C++ is likely your best option, but I would seriously gel on it before throwing down that gauntlet.
I have a library written in standard C++. I also have a .Net windows form app written in C# that utilizes the unmanaged library.
I understand I can just use pinvoke, but my C++ is completely OO and I really wouldn't want to mess around with marshaling and such.
Is there a way that I can just create a new managed C++ dll project, copy and paste my header and code files, and compile it and have access to all the classes?
Or would I have to create some ref class in managed c++ and hook it up to my unmanaged class? I just want this to be as simple as possible.
Thanks!
You would still have to write specific .NET wrappers even in C++/CLI, they just look different. So the answer to, can you put it in a C++/CLI project and recompile and use it as is, is no. You still have to either marshal the data over (in which case you may as well use p/Invoke probably) or you can create handles and use pinned memory to make your structures available to managed code.
I've done this both ways: I've written a GPU library in CUDA C and called it from F# using p/Invoke and I've written a video processing library in C++ and written a thin C++/CLI wrapper then used it in a .NET app. I think the CLI wrapper was more painful, but for live video I needed less latency (less copying memory). For the GPU project I was more concerned with throughput.
You are probably going to want to write the wrapper classes in C++/CLI. It's fairly trivial to do, as long as you return handles instead of pointers, enumerators instead of collections, etc.
I need to build a C++ library to distribute among our customers. The library must be able to be accessed from a wide range of languages including VB6, C++, VB.net and C#.
I've being using ActiveX controls (ocx files) until now. But I wonder if there is a better kind of library (dll, etc.) that I can build. What do you recommend?
I'm limited to C++ as the library language, but you can mention other languages for reference to other developers.
P.S. Sorry if the question was already asked. I had some trouble finding a suitable title. Feel free to correct my English.
Edit: Seems like the best choice is either DLLs or OCX (i.e., COM), but I'm still having some doubts on which one will I choose. Which one is more suitable to modern languages (.NET for instance)? Which one would be easier to use from an end developer perspective?
Almost every language has a way of loading dynamic libraries and accessing exported C functions from them.
There is nothing preventing you from using C++ inside the dll but for maximum portability, export only C functions.
I have some more about this in this post.
If you're looking at supporting both VB6 and .NET, you're pretty much stuck with exposing interfaces via COM, but at least that'll get you out of having to create more than one wrapper based on the language/runtime system you're trying to interact with.
If there is any chance this will need to be ported to non windows platforms then a DLL / Shared library is your best choice as a COM object really isn't at all portable.
In addition you can call a DLL from almost any platform even if it requires you to write a wrapper of some kind. It's pretty easy to wrap a dll in a com object but if you make a native com object it's a lot harder to add a C style DLL API. Plus you might want to call it from java for example and it's much easier to write a JNI wrapper to call your DLL than get it working with COM in any kind of cross platform way.
Really it depends on what platforms you really need to call it from and how certain you can be that you won't get something out of the ordinary in future.
To be callable from all those languages your only real option is going to be COM, without having to write wrappers where required (which would defeat the point)