CppSharp Developers Manual
The driver is responsible for setting up the needed context for the rest of the tool and for implementing the main logic for parsing the user-provided headers, processing the declarations and then calling the language-specific generator to generate the bindings.
Since writing bindings by hand is tedious and error-prone, an automated approach was preferred. The open-source Clang parser is used for the task, providing an AST (Abstract Syntax Tree) of the code, ready to be consumed by the generator.
This is done in Parser.cpp, we walk the AST provided by Clang and mirror it in a .NET-friendly way. Most of this code is pretty straightforward if you are familiar with how Clang represents C++ code in AST nodes.
Recommended Clang documentation: Clang Internals manual
After parsing is done, some language-specific binding code needs to be generated.
Different target languages provide different features, so each generator needs to process the declarations in certain ways to provide a good mapping to the target language.
Additionally some of it can be provided directly in the native source code, by annotating the declarations with custom attributes.
This implements the C++ implementation-specific behaviours that allow the target language to communicate with the native code. It will usually use an existing FFI that provides support for interacting with C code.
It needs to know about the object layout, virtual tables, RTTI and exception low level details, so it can interoperate with the C++ code.
Each ABI specifies the internal implementation-specific details of how C++ code works at the machine level, involving things like:
- Class Layout
- Symbol Naming
- Virtual tables
- Exceptions
- RTTI (Run-time Type Information)
There are two major C++ ABIs currently in use:
- Microsoft (VC++ / Clang)
- Itanium (GCC / Clang)
Each implementation differs in a lot of low level details, so we have to implement specific code for each one.
The target runtime needs to support calling native methods and this is usually implemented with an FFI (foreign function interface) in the target language VM virtual machine). In .NET this is done via the P/Invoke system.
- SWIG http://www.swig.org/
This is the grand-daddy of binding tools and supports a lot of different languages and environments. It uses a unique approach of mixing the customization of the binding in interface files that it also uses to specify the native declarations. This is possible because SWIG contains its own parser for native code.
- SharpGenTools https://github.com/SharpGenTools/SharpGenTools
This tool uses CastXML for C++ parsing, whereas CppSharp relies directly on Clang and is able to get
very accurate information not just for C++ types and declarations, but also ABI-specific codegen
details. SharpGenTools uses the calli .NET IL instruction for indirect calls which can lead to
higher performance code in some cases. CppSharp does not use this because its not available from C#
and needs a separate post-processing build step to modify the .NET assembly after compilation.
This can be seen as the precedecessor to CppSharp and relied on a different binding approach, generating IL code at runtime for each C++ ABI and using the GCC-XML tool for parsing.
In comparison, CppSharp generates different code at compile-time for each ABI and relies on Clang for parsing.
- Sharppy - .NET bindings generator for unmanaged C++ https://code.google.com/p/sharppy/
Looks abandoned at this point.
- XInterop http://xinterop.com/
Commercial tool.