I am trying to evaluate Djinni, for generating Java and Obj-C wrappers from our C++ code.
We currently use SWIG and are evaluating other tools for wrapper generation.
Due to some restriction at my work place our C++ code is in C++-98.
We cannot migrate to C++-11 due to some customer needs.
As such I wanted to know if I can use Djinni, with C++-98.
Djinni github readme states:
Interfaces are objects with defined methods to call (in C++, passed by shared_ptr). Djinni produces code allowing an interface implemented in C++ to be transparently used from ObjC or Java, and vice versa.
I saw couple of sample's using Djinni over the internet and they all seem to use shared_ptrs with their interfaces.
Is C++-11 mandatory for using Djinni?
No, Djinni can not be used with C++98. It uses C++11 pretty extensively, both in the generated code and in the support library, so it can't support C++98.
Related
Can v8 (Google's open source JavaScript engine) be used with C++11?
https://developers.google.com/v8/embed
The V8 API provides functions for compiling and executing scripts,
accessing C++ methods and data structures, handling errors, and
enabling security checks. Your application can use V8 just like any
other C++ library. Your C++ code accesses V8 through the V8 API by
including the header include/v8.h.
It´s a sublink of the one you commented, i hope it helps.
Yes, as of today it can be used effectively with C++11, and even C++14 semantics. I had this same question while writing a v8 project, which uses a multitude of C++11 (and later) threading features.
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...
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 in the process of writing a C interface to a C++ library, and I'm looking for some high-quality examples (or best practices).
So far this one seems pretty promising: http://czmq.zeromq.org/manual:czmq
Any other suggestions?
You could look into the Parma Polyhedra Library as an example of excellent C interface to a well written C++ library. PPL is a free GPL-ed software, notably used inside the GCC compiler.
Another high quality example is the Open Dynamics Engine. It has a C++ backend and a C frontend. Everything is C linkable.
C++ example
C example
If your C++ library is written as COM on Windows. There are tools to automatically generate the C interface for it.
I can suggest FTGL which is a C++ library providing a C interface. Here are two sample programs that achieve exactly the same thing:
C++ version
C version
Note also that FTGL uses the pImpl paradigm in order to achieve binary compatibility across versions. See here why it's good.
Disclaimer: I'm an FTGL contributor.
libGLU (OpenGL Utility Library) is partially written in C++: http://cgit.freedesktop.org/mesa/mesa/tree/src/glu
libzmq is a kind of weird case since the low-level C API was originally meant to look like POSIX sockets, and absolutely not object-oriented (we made it more consistent and organized over time). Meanwhile the actual library is in C++.
The C++-to-C interface is in libzmq/src/zmq.cpp, and consists of a bunch of simple C functions that call the 'real' C++ code.
CZMQ on the other hand aims for something more classy, providing a simple class model with constructors, destructors, containers, private properties, etc. Nothing radical but does turn C into a much more elegant language.
I'm not sure how well the CZMQ class approach would map to a C++ API unless that API was explicitly designed to be mapped.
Disclaimer: I'm the author of most of CZMQ.
Are there any high level language that don't support using C++ libraries?
Using C++ libraries from other high-level languages has a couple of major obstacles:
if the library is OO, you need to be able to create a C++ object in the calling language - this is not easy.
C++ implementations use a technique known as "name-mangling" to ensure type-safe linkage. Unfortunately, there is no standard for name mangling, so C++ code cannot even easily be called between different C++ implementations.
So the answer to your question is that most HLLs will have problems calling C++ code. They may also have problems calling any other language of course - there are actually no standardised binary interfaces between languages, except ad hoc, platform-specifc ones.
I can't think of any language that is able to use C++ libraries directly. Even getting C++ to do it can be tricky (if the library was compiled with a different compiler than you're using)
Of course, if you write a wrapper of some kind (either a wrapper for the specific library, or some kind of bindings library that lets you expose specific types), then any language can use C++ libraries. But directly, as-is, with no extra work? I don't think any language other than C++ can do it.
This is a bit of an anti-answer, but many popular high-level languages can have bindings to C++ library code created for them via swig (http://swig.org/).