I have a C/C++ .dll containing core functionality of my program, and a Delphi project for the graphical user interface.
Is there any way I can export something like a std::vector or std::map to Delphi and use it in C++?
Thanks in advance
C++ classes can only be directly consumed by C++ code. Similarly, Delphi classes can only be directly consumed by Delphi code.
An exception to these rules is that Embarcadero's compilers have interop support and it is possible to consume some Delphi classes from C++ code, so long as the C++ code is compiled using an Embarcadero compiler.
Assuming that you are not using an Embarcadero C++ compiler you will need to wrap any classes that you wish to export in an interop friendly manner. The obvious choice for this is COM which was designed to solve this very problem.
Related
I need to use a 3rd party code/dll in my .Net service. I did some research. But I can't find any direct answer for this. Mostly are recommending to port the code into VS C++ .net using a wrapper class. At the same time since there are VCL-headers used which has no replacements in VS C++. Can someone guide me on this please?
The VCL files in use are : Classes.hpp, Sockets.hpp and, ExtCtrls.hpp
Thanks in advance.
A DLL written in C++Builder works just fine in C# provided that the DLL exports flat C-style functions that use basic interop-safe data types and calling conventions that are portable across multiple compilers. Or the DLL implements a COM object (since COM has a standardized ABI). This is no different than writing any DLL that can be used in multiple languages including Delphi, VB, Java, Perl, PHP, etc.
You can't use VCL headers directly in the DLL's public interface, since VCL is not portable to non-Delphi/C++Builder compilers. But you can hide the VCL code behind an abstraction layer that is portable.
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.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What is the difference between Managed C++ and C++/CLI?
What is CLI/C++ exactly? How does it differ to 'normal' c++?
I am in doubt of distinguishing between C++ and C++.NET.
Is that right C++ is unmanaged code and C++.NET is managed code?
I need to program for a project in C++. For better building the GUI, I would prefer to use C++.NET.
I also have another plain C++ library (unmanaged C++ DLL file), will it be possible to use it as a normal DLL library in the C++.NET project?
Is that right C++ is unmanaged code and C++.NET is managed code.
There's no such thing as "C++.NET". There's C++/CLI, which is basically C++ with Microsoft extensions that allow you to write code targeting the .NET framework. C++/CLI code compiles to CLR bytecode, and runs on a virtual machine just like C#. I'll assume you're actually talking about C++/CLI.
With respect to that, one can say standard C++ is unmanaged and C++/CLI is managed, but that's very much Microsoft terminology. You'll never see the term "unmanaged" used this way when talking about standard C++ unless in comparison with C++/CLI.
Both standard C++ and C++/CLI can be compiled by the same Visual C++ compiler. The former is the default on VC++ compilers, while a compiler switch is needed to make it compile in latter mode.
I need to program for a project in C++. For better building the GUI, I
would prefer to use C++.NET.
You can build GUI programs in C++ just as well as C++/CLI. It's just harder because there isn't a standard library in standard C++ for building GUI like the .NET framework has, but there are lots of projects out there like Qt and wxWidgets which provide a C++ GUI framework.
I also have another plain C++ library (unmanaged C++ dll), will it be
possible to use it as a normal dll library in the C++.NET project?
Yes. It might take some extra work to deal with the different standard C++ data types and .NET data types, but you can certainly make it work.
Managed C++ is a now deprecated Microsoft set of deviations from C++, including grammatical and syntactic extensions, keywords and attributes, to bring the C++ syntax and language to the .NET Framework. These extensions allowed C++ code to be targeted to the Common Language Runtime (CLR) in the form of managed code as well as continue to interoperate with native code. Managed C++ was not a complete standalone, or full-fledged programming language.
Managed C++
#using <mscorlib.dll>
using namespace System;
int main() {
Console::WriteLine("Hello, world!");
return 0;
}
Vanilla C++
#include <iostream>
using namespace std;
int main()
{
cout << "Hello, world!";
return 0;
}
Well... C++ .NET is kind of a misnomer.
You can program in C++ using visual studio .NET. Well that's what it was called along time ago. Now a days folks just call it Visual Studio, with the dot NET moniker. Well, at least the splash screen doesn't have a big ol .NET in the logo anymore.
It is kind of understood that using Visual Studio (VS), you can program in managed and unmanaged languages (Lots of choices there btw).
If you want to program in C++ using Visual Studio you have two choices:
Unmanaged or native C/C++. This is the old (or new I guess too) C++
that you have always known, and you program with unmanaged memory.
Managed C++. They call this C++/CLI. That is read C++ over CLI, not
C++ divided by CLI! This is C++ that has extra keywords, and a few
extra syntax elements than the native C++. This allows you to
utilize the .NET Foundation Class Library and do other fun things in
the .NET framework. This of course uses the garbage collector for
memory for managed types.
Personally my favorite language is C#, but if you need to interop between C++ and .NET than definitely use Managed C++. It is very easy to do, and I think is easier than that other P/Invoke stuff.
If you are going to some project, I would suggest you do your UI in C# and take advantage of all that it has to offer. Then have that reference a mixed mode managed library that contains your C++ code. I think that will be a lot easier for you.
The answer to your last question is yes, you can definitely use that in your app.
Here is how the dependencies would work:
[C# App/GUI] depends on [Managed C++ assembly] depends on [Native C++ Lib]
Yes, C++ is unmanaged code and C++/CLI is managed.
Yes, you can use your unmanaged C++ DLL in your C++/CLI project. But you have to write a wrapper for that. That means you have to define the unmanaged methods you want to access in your C++/CLI project.
Example:
using System.Runtime.InteropServices;
[DllImport("YourDLLName")]
public static extern void UnmanagedMethodName(string parameter1);
I have a C++ program that I wrote, and I would like to give it a user interface. Is there any way I can run a C++ program and put the information from the program onto the UI of a VB Application?
Sure.
Use
COM
COM Interop
P/Invoke (a.k.a. Declare in VB)
Oh, I forgot: C++/CLR if you intend to use Windows only
I suggest you write the whole application in a managed language (e.g. VB.Net) and only invoke C++ library functions for the performance critical work (or for legacy code that you already have, of course).
I think the easiest solution would be to put your C++ code into a DLL, and call your code from VB. Have a look at this article for more information...
http://www.codeproject.com/kb/DLL/XDllPt1.aspx
you can mix C++ and .NET
easiest is if you target your C++ code to the CLR, but you can also mix .NET and native code.
either way you basically make your C++ program a library your VB code can use.
Considering Simon Mourier's answer to this question:
Processing Microsoft Office Outlook 2003/2007 email messages…
I plan to use the PST File Format SDK which is written in C++.
I would take this opportunity to learn more about C++ and to renew with it, since it's been quite 15 years since the last time I used it. I have already downloaded and configured Boost 1.45 which is required to work with pstsdk.
Now, I'm currently writing a Windows Forms application using CLR C++ and plan to use the pstsdk to read from PST files.
Does it matter in any way that I'm using both CLR C++ and pure C++ altogether?
Shall I consider using it a different way, or is this okay?
If you want to use a .NET (Windows Forms, or maybe even the newer WPF) user interface, the simplest approach is to build an object model in C++/CLI, implemented in terms of the native code but having a .NET interface.
Then write the UI in C# and call the C++/CLI object model (which differs from using the .NET base class library in only one way -- you have to add a reference to the C++/CLI assembly... but the C++/CLI compiler will create all the metadata that C# uses).
You can mix managed and unmanaged code, but it will be a pain to marshal everything except the built-in types across the boundaries. It's much easier to stay with more powerful unmanaged C++. You could use CodeGear C++ Builder for example (or QT). The problem with CodeGear is compiler isn't that great, so you won't be able to compile everything from Boost, but you might not need that.
C++/CLI is intended to interop with unmanaged C++- that's pretty much it's entire purpose. However, I feel that it's probably easier to write in C# if you need .NET for, say, WPF, which is an excellent technology, and just use C++/CLI for interop.