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.
Related
With native c++, I mean, not managed c++, not cli, not any special things from microsoft, I can:
1) get high performance
2) use existing c++ code library and engine
3) write cross platform code (for example, for ios and android)
it needn't be fully native c++, I can use managed code to do the ui things, like object-c in ios and java in android, but beside interface, can I use native c++ code?
I suggest you have a look at the presentation here: Using the Windows Runtime from C++ and especially at the comments from Herb Sutter. I quote:
Please answer this question: If I decide to write C++ GUI application
in Metro style am I forced to use all these proprietary ref, sealed,
^, Platform::String^ extensions for GUI components or not?
#Tomas: No, you are not forced to use them. We are providing two
supported ways:
1) These language extensions (C++/CX).
2) A C++ template library (WRL), see
Windows Kits\8.0\Include\winrt\wrl as Yannick mentioned. WRL is a C++
library-based solution sort of along the lines of ATL, which offers
what I think you're looking for -- template wrapper/convenience
classes and explicit smart pointers and such.
Yes you absolutely can, real native C++ is fully supported.
You do however mostly have to use the new WinRT libraries to do an user interface or system calls and although they are native code and fully callable from C++ directly the interface to them makes it very painful indeed to do so, as everything is a reference counted COM object and in addition it's not so easy to create instances of them as just calling "new" so you have to write a lot of ugly code to do so.
As the earlier answer said, microsoft provide two ways to help with this. One is via language extensions to c++ and the other is a c++ template library. Personally I consider both to be rather ugly for doing something as simple as calling an API but that's just me :)
But to answer your question, it's completely possible to write your application in real native c++. You won't need to use managed code at all for anything. But you'll probably want to use either the language extensions or the template library to make calling the API more easy.
Personally I'm hoping someone writes a wrapper for WinRT that exposes the most necessary functionality as a more usable c++ native library and then everyone can just use that from c++ instead...
Hey so for one of my c++ projects I need to develop a 4-5 window application.Now the issue is that currently all of my programs tasks are divided into classes, and I have tested them by passing 'dummy' values and returning print results. That's all fine and working, however now as I want to introduce a GUI interface it presents me with the problem of how my processing should communicate with the front end, since winAPI is initially meant for c and not object oriented language.
What I am thinking of doing, and have a feeling is going to be a tedious task, to make a class which does the win api's registrations and methods for me. Is there any other alternative to this ???
I was looking at integrating Qt into eclipse but I think they stopped providing the library for eclipse, because I couldn't find a download for the library anywhere, not even on the Qt download page.
Well, if you want to use Win32, then you have to do all the stuff that Win32 needs you to do. It's a rather low level API, so you just have to take care of a lot of details.
However, don't over-engineer things. You don't have to write a generic C++ wrapper for Win32... you just have to make a GUI for your program.
If your problem is only that classes are not supported by C, then simply replace the keyword class with the keyword struct. Just make sure to declare the access types of all variables (private, public, protected), that way it becomes interchangeable (Works for both). The only difference between them is the default access type, which for classes is private. In case you used other syntax that is unique to C++, then this wouldn't work.
There are code generators from C++ to C as well. The optimal solution would be to create a GUI using an IDE specifically for that purpose which uses C++ as its base language. MFC works well, but it is not open-source and you will need a considerable knowledge on inheritance and comfort with "class typecasting". Using the included wizards in Visual Studio will help.
Try the first option; it will possibly work the same way.
Suppose I have two projects that I would like to link together:
A C++ library compiled with Visual C++ to a DLL file.
A C++ executable compiled with C++ Builder that uses the classes in the library.
I realize that there is no standard C++ ABI and that any attempts to directly link these two C++ projects together will fail. What is a good, automated way of creating a compatibility layer that allows me to accomplish this?
For example, conceivably the C++ library could expose itself via a C interface. Then the executable would have some C++ classes that wrap the C interface exposed by the C++ library. Since there is a standard ABI for C, it would work.
The only question is how to automatically create the C interface and C++ wrapper classes - manually maintaining this would not be an option. The SWIG project looks promising, but unfortunately, C++ is not one of the exits of SWIG listed on their web site. Is there a way to do what I want with SWIG? Or is there another project other than SWIG that would help me with this task?
Or am I going about this the wrong way?
Edit: The core C++ library is intended to be cross-platform. The executable, obviously, is Windows-specific. I don't want to pollute the core library to the extent that it becomes impossible to compile it on other platforms.
If it only has to run on Windows, I would expose the classes as COM objects. They'll still be in a DLL and they can be used by any language which understands COM.
The "standard" way of doing this, in Windows, is to use COM objects. So, that is certainly a good option to look at. In Linux systems, the module interaction model (e.g., executable-DLL interaction) is very different, and ABIs exist for C++.
If you would want to do this manually (create your own COM-like library), it can be a lot of work with many little tricky issues to take seriously. You'll need a cross-module RTTI system, you'll need an interface query/definition protocol, some mechanism to manage memory across modules, etc. Beyond that, to "automate" it, you will probably need a combination of MACROs and template meta-functions.
One cross-platform option that I would highly recommend that you consider or at least look at is using Boost.Python and the Python language as the "glue" between your modules. The Boost.Python library basically does the whole "automated exporting / importing of classes", but it exports your C++ classes and functions as Python classes and functions. And, it is completely non-intrusive and cross-platform, so this is really an ideal example of automated exporting. So, you might consider using Python to write your high-level glue-code, or using Python as an intermediate between the C++ modules, or even reworking the Boost.Python library to use only the "automated exporting" mechanisms to export to whatever interface system you design or use.
I'm sure there a plenty other similar libraries out there. But the number one question is, of course, do you really need this? You might be using a bazooka to kill a fly.
Why not just compile the library with C++ builder as well?
Looking around at swig (I knew swig should be able to wrap C++ in C):
SWIG and C++
If core library is cross-platform why not also write the UI as a cross-platform Qt application and build everything in Visual C++ on Windows.
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).
I like C++ a lot and to be honest the Objective-C "super set" of C is more of a "super fail". Can an iPhone application be written in pure C++? Are there parts of the API that are unavailable from C++?
You can't code purely in C++. For one, the UIApplicationDelegate class every application needs to inherit is Objective-C.
However, nothing is stopping you from coding everything that isn't framework related in Objective-C++. You'll still need to use the Objective-C calls for UIKit and other frameworks, but all of your application logic can be in C++.
From the Objective-C++ section of the Objective-C programming guide, these are the main limitations:
Objective-C++ does not add C++
features to Objective-C classes, nor
does it add Objective-C features to
C++ classes. For example, you cannot
use Objective-C syntax to call a C++
object, you cannot add constructors or
destructors to an Objective-C object,
and you cannot use the keywords this
and self interchangeably. The class
hierarchies are separate; a C++ class
cannot inherit from an Objective-C
class, and an Objective-C class cannot
inherit from a C++ class. In addition,
multi-language exception handling is
not supported. That is, an exception
thrown in Objective-C code cannot be
caught in C++ code and, conversely, an
exception thrown in C++ code cannot be
caught in Objective-C code. For more
information on exceptions in
Objective-C, see “Exception Handling.”
Some Carbon APIs exist in the iPhone so you will be able to access them from within a purely c++ application. That being said, however, there are a lot of very important APIs that are Objective-C only (e.g., UIKit). With some good design decisions a reasonable C/C++ shim could be written to encapsulate the Objective-C necessary to get an iPhone application working. Once that's done you'd be able to write your app with traditional C++ no problem.
The way Objective-C++ is set up you can still write bona fide C++ and mix-in Objective-C calls where necessary. This has been the route I've taken in the iPhone applications I have developed.
I don't think that you'll manage to completely escape objective-c for any meaningful application, but you are free to code mostly in C++. In fact, sio2(one of the iphone game engines) is mostly C++ if you were to use that as the base for your application you could probably avoid writing objective-c yourself.
I would like to know what you don't like about objective-c? I came from a C++ background and find Obj-C to be refreshing and more OO than C++.
You only need to do the GUI in Obj-C (Obj-C++).
There is no problem with integrating any other C++ code with the interface. Just be carefully to manually delete your pointers that are held inside Obj-C objects