1

I have read that there are languages other than C++ that can also compile standard C++ source code too (Objective C++ can do this). Which other languages for Windows and Mac OS are there, that support this too? In contrast to Objective C++, are there also languages available which allow to derive a native class from a C++ class?

Please do only answer regarding hybrid compilation. I am already aware of scripting and DLL calling solutions.

8
  • 2
    Have you looked at SWIG? Commented Mar 25, 2016 at 2:41
  • See: Hourglass interfaces for C++ APIs
    – rwong
    Commented Mar 25, 2016 at 3:55
  • 1
    Take a look at Lua Commented Mar 25, 2016 at 4:23
  • 5
    The direct answer to your question is "all of them, but some are harder than others". So when you say "mix with C++ code", are you talking about languages that provide some built-in support for calling C++ functions, or languages where it's possible to call C++ functions given some effort, or languages that can be freely intermixed with C++ the way C can be mixed with C++ or Objective-C? (unfortunately open-ended list questions like this are off-topic here but we can maybe give you a hint if we know what you're after)
    – Ixrec
    Commented Mar 25, 2016 at 7:59
  • 1
    this question is discussed at meta
    – gnat
    Commented Apr 1, 2016 at 13:57

3 Answers 3

6

A lot of languages allow interfacing to C and thus C++ by use of extern "C". For example, Java has JNI and C#/VB have DllImport, even QBASIC can interface with C code.

So you can interface C++ code with quite a few languages if you're willing to write the interfaces for your code to do so. But since you're specifically asking what languages have "native support" for C++ like Objective-C++, that list shortens substantially, even Object-C++ has restrictions on how you can "mix" the code.

From a short search (since there are thousands of programming languages), a few I found are as follows:

It should be noted that some of these languages are interpreted languages (like R) or a complete platform (like CUDA), and just because it supports you using C++ code does not mean that it will support the C++ standard library (or even strictly adhere to the C++ standard itself), so more investigation would need to be done for those instances.

Depending on what you're trying to provide, using the external C linkage in your C++ might yield a wider array of other langauges to interact with.

Hope that can help.

3

Almost all of the .NET based languages have support for calling external DLLs using a C interface.

You would accomplish this in C# by defining a method call using the extern keyword. You can find much more information here.

The extern modifier is used to declare a method that is implemented externally. A common use of the extern modifier is with the DllImport attribute when you are using Interop services to call into unmanaged code. In this case, the method must also be declared as static, as shown in the following example:

// C# version
[DllImport("avifil32.dll")]
private static extern void AVIFileInit();

' VB version
<DllImport("avifil32.dll")> _
Private Shared External Sub AVIFileInit();

You should also look up information about the DllImport attribute.

Mono also supports this type of call.

The Common Language Infrastructure (CLI) is designed to make it “easy” to interoperate with existing code. In principle, all you need to do is create a DllImport function declaration for the existing code to invoke, and the runtime will handle the rest. For example:

[DllImport ("libc.so")]
private static extern int getpid ();
1

All .NET languages can be 'mixed' with C++ in the sense that you can use Managed C++ (a.k.a. C++/CLI) to expose C++ libraries/APIs towards .NET. The process is essentially manual (unlike SWIG) but it is nowhere near as lossy and awkward as DLL interfaces, and it can be a lot less painful than exposing a library via COM.

Managed C++ can also solve the reverse problem, i.e. accessing .NET libraries from 'plain' C++ code. It's advantage is that it allows much richer APIs and tighter integration than plain DLL interfaces and (raw) COM, with a lot less work.

Not the answer you're looking for? Browse other questions tagged or ask your own question.