Is it possible to call C++ class library from delphi 2007? What is the way of doing that? I know how to call dll function, but how to deal with class?
There are several ways to do this, but you can't use a C++ class directly. Both useful ways to achieve this require some work and are extensively described here:
Using C++ objects in Delphi (http://rvelthuis.de/articles/articles-cppobjs.html)
Update
OK, I was asked to do an update. The article describes two ways:
Writing and exposing C functions that take the C++ object as (first) parameter (the C++ type is simply passed on as opaque type in Delphi), which simply perform the functionality the class provides by calling the class methods with the right parameters. The C functions can be called from Delphi.
Writing a COM wrapper for the class. The article describes how this can be done in C++.
Details can be found in the article.
You cannot consume C++ classes from Delphi. You will need to wrap them in some other interop friendly manner. For instance:
Wrap the C++ classes with C style functions that expose the functionality.
Expose COM objects that provide the functionality.
Related
I need to make gui application that must call c++ dll class functions. What programming languages are able to call class functions without problems? By problems I mean wrappers and similar things.
Why you don't make the GUI directly in c++?
QT is a well known and mature framework, for instance
C functions in a DLL can be called from most languages.
C++ functions, particularly with classes are difficult at best. Probably they will cause you more trouble than it is worth.
My advice is to just use C++ and prevent the problems.
If you insist on building your GUI with another language X, then your best approach would be to write a glue DLL, written in C++, that shows a C-only interface to the X-GUI and accesses the target C++ classes directly.
I'm trying to develop an application that can "stack" FITS images. To read FITS images I can either use CCFits (a C++ library) or CFITSIO (A C library) - there is no native Objective-C library.
I would prefer to use CCFits as it allows object-oriented design which I'm hoping will allow me to organize the program better. I've already tried to use CFITSIO but it gets rather unwieldy after a while (of course, this could be because of my inexperience in developing large applications).
So overall, what's the best way to approach this? Should I write wrappers for the CFITSIO functions and write my own classes? Is there a way to use C++ classes in Objective-C - the library contains quite a few classes and I know I can use opaque pointers to wrap around the classes, but how would things like class inheritance be preserved? Will I have to subclass a class in Objective-C manually and wrap the subclass there?
You can easily mix C++ and Objective-C using Objective-C++. In XCode just rename your .m files to .mm and it will recognize the files as Objective-C++. Then you can use the C++ classes in your Objective-C code (some restrictions apply, but not many).
Since Objective-C is an extension to C you can use C libraries in any Objective-C program easily.
Mixing C++ and Objective-C is easy, as #myrkos says.
However do make sure you read up carefully how the two languages interact.
In particular you cannot inherit an Objective-C class from a C++ class, or vice-versa (which you seem to allude to in your question).
That's not usually an issue in practice.
They compose very nicely, however (that is you can have an Objective-C object as a member of a C++ class and vice-versa - as long as it's all in a .mm file).
If you hold a C++ object as an ivar of an Objective-C class by value then constructors and destructors will be called for you automatically.
So overall, what's the best way to approach this?
Use the variant you are comfortable with (CCFits).
Should I write wrappers for the CFITSIO functions and write my own classes?
No.
Is there a way to use C++ classes in Objective-C - the library contains quite a few classes and I know I can use opaque pointers to wrap around the classes, but how would things like class inheritance be preserved?
Objective-C++ allows you to use C, Objective-C, and C++ programs in the same translation with very few issues. Therefore, your implementations can mix Cocoa and C++ as needed. C++ classes can hold ObjC types, and ObjC types can hold C++ types.
Will I have to subclass a class in Objective-C manually and wrap the subclass there?
Just use the CCFits library as-is. There is little to gain by wrapping it in ObjC types, and a lot of time to lose.
If you want to stick with strict ObjC in some areas, then you will need to learn how to hide C++ types behind ObjC interfaces (not a wrapper interface -- just a high level interface for your app's usage of CCFits).
Sorry if this question seems obvious for everyone, but I am very new to COM. From the tutorial I see here http://www.codeguru.com/cpp/com-tech/activex/tutorials/article.php/c5567, it seems like every COM class created in C++ must implement its own QueryInterface, AddRef and Release. Since these methods should have basically the same implementation for any new class, I don't understand why there isn't some abstract class or whatever that implements it for the developer. I don't understand why I should re-implement the same thing that so many people have already implemented again and again (unless the tutorial is wrong and there IS something).
Thanks
FTA:
"I believe that every programmer who wishes to understand the basic principles behind COM, must write atleast one simple COM object using plain C++ , i.e. without the aid of templates and macros that comes along with MFC/ATL."
To answer your question: Yes, every COM component must implement IUnknown, it's the foundation COM is built on. However, as for the "standard pluming" for creating COM objects this is what the ATL Project Wizard is for.
If you don't want to use ATL or other helper libraries you can use the QISearch helper function that handles QueryInterface for you. AddRef and Release can be implemented in your own base class.
COM needs to work with plain C also so the windows sdk does not really go beyond the definition of the class and its methods.
Yes, every COM class must implement IUnknown, because every COM class inherits from IUnknown - that's one of the basic COM technology principles. This is usually done by using ATL - it has templates and macros for doing that rather easily and even if you don't want to use ATL you can write a template for most trivial cases (like implementing one interface) pretty easily and reuse that.
I have followed the steps here to create a COM DLL in Visual Studio 2008. My objective is to wrap an existing unmanaged C++ .lib.
Is there an easy way to implement the COM interface for the lib. Or do I just have to keep adding ATL simple objects which essentially wrap the objects in my library?
For example, I have added the simple ATL object, CMyObject to my COM library, am I to create wrapper code including function members etc in CMyObject that essentially wrap the behavior of MyObject contained in the unmanaged C++ library?
In order to expose your functionality to COM you'll need to perform two major steps:
introduce COM interfaces
implement those interfaces using functionality of code you already have
So yes, the scenario you described is the typical way to solve this problem.
Using ATL will simplify things a lot. However you have to take care of exceptions as well. Since your code is in C++ it can throw exceptions. COM doesn't allow propagating exceptions outside COM methods - if the client is not in C++ it will crash once exception is thrown from your code. So your wrapper layer needs to have try-catch for every method directly called from COM.
I think adding wrappers the way you describe is the best way to go. Given that parameter types for OLE will be different to the C++ parameters in many cases, e.g. BSTR rather than string or char*, some wrapping is required for COM. The only alternative is to have a non-COM DLL.
I'm working on a C++ project with a large number of classes (150+), each of which has anywhere from 10 to 300 fields or so. I would really like to be able to provide a scripting interface for testing purposes so that I can code callbacks that don't require any re-compilation. I'd like to do this in Lua since I'm more familiar with its C API than I am with Python's, but if it will save headaches I'd be happy to do it in Python.
I've got a solid grasp on how to call Lua functions from my C++ and vice versa, and I know how to pass basic data types back and forth. The question I have is how to share user-specified data types between the two using SWIG.
For example, at some point in my C++, I might want to evaluate a couple of pieces of member data in an object that has 250 fields. I'd like to be able to hand that object off to Lua which could then (hopefully?) use the generated SWIG wrappers to manipulate that object, display certain fields, and then pass the (potentially changed) object back to C++ for continued use.
I would also like to be able to instantiate an instance of the object in Lua using the wrappers and pass it off to C++ to be used as a normal C++ version of the object.
Is this possible? Could somebody point me towards a tutorial or an explicit example?
Thanks for any help you can offer!
As long as you wrap your user-defined types using Swig interfaces (see here for documentation on Swig-Lua API), the interaction should be seamless. The provided Swig wrappers will allow you to instantiate new objects, pass them along to C++ and vice-versa.
I do not believe that Swig-Lua wrapping supports director classes yet, which means that extending existing classes, instantiating them and passing them back to C++ is not possible. Directors are supported for languages such as Python, Java, C# though.
If swig gives you trouble, I've had good luck with the latest version of tolua++, which is for the sole purpose of binding C++ and Lua. It requires a modified .h file as input, which is a bit tedious, but no more so than Swig's modules. I have no reason to prefer one over the other, but it's good to know about both.
You should also check out Luabind. This one implements OOP for Lua and can map classes and data types from Lua back to C++.