Exploring C++ ABI Boundaries for FFIgen

[Sagar Halladakeri]

Hi Liam and Brian,

I’ve been exploring what practical C++ support in FFIgen might look like and ran a small experiment locally to make the ABI constraints concrete.

I implemented a minimal Calculator class and generated a C-compatible wrapper using extern "C" with opaque handles. I built the shared library twice, once with C linkage and once without, and inspected the exported symbols using nm -C.

With C linkage:

Without C linkage:

With extern "C", the wrapper exports clean, stable symbols:

_calculator_add

_calculator_create

_calculator_destroy

Without it, the same functions resolve to ABI-mangled C++ symbols (e.g. __Z14calculator_addP16CalculatorHandlei), which nm -C demangles for readability but remain compiler-specific at the binary level.

Seeing that contrast directly reinforced a few things for me:
Seeing that contrast made it clear to me that C++ name mangling encodes types and context into symbol names, but since each compiler does it differently, the results aren’t consistent. That’s why Dart FFI relies on a stable C ABI surface, so it can interact with native code in a predictable way.

That makes a generated C-compatible wrapper layer feel like the only realistic boundary for interop.

The main question I’m trying to clarify is this:

Do you envision initial C++ support in FFIgen being intentionally limited to a constrained subset of C++ (e.g., non-templated, non-overloaded APIs), or should the wrapper generation aim to systematically expand overloads and templates into distinct C entry points from the start?

If there’s a small real-world C++ library you’d recommend prototyping against, I’d be glad to attempt a minimal parse -> wrapper generation -> Dart binding pipeline and share what I learn.

Best,

Sagar

[Liam Appelbe]

Hi Sagar

Definitely start with a subset of C++:

• Classes and methods would be the top priority. Then probably the inheritance hierarchy.
• Make sure to consider memory management. Eg, how should we handle APIs that contain std::unique_ptr/shared_ptr? How do these interact with Dart's GC? Maybe we need special wrappers for these, using finalizers to clean up the references? What about functions/methods that pass classes by value? It will probably also be important to detect whether a class/struct is POD (plain-old-data: no custom constructor/destructor, no virtual functions, no base classes, all fields also POD).
• Namespaces are also high priority. How can we translate those to Dart?
• Translating C++ templates to Dart generics will be important, but difficult, since there's probably a lot of semantic differences to work around. The config format will need a way of instantiating the templates for specific concrete types, since C++ templates are not compiled into the final binary unless you ask for specific instantiation. This is probably out of scope for the GSoC project, but we can start thinking about it now.
• Translating STL types to corresponding Dart types will also be a big but important job. Notably the collection types, and std::function. To make this a fully polished project we'll probably need a helper library like package:objective_c/package:jni that contains Darty looking wrappers around the C++ collections, but that's way out of scope for the GSoC project.
• Operator overloads are lower priority, but nice to have and should be pretty easy once we have classes and methods.
• C++ exceptions are very low priority, because in my experience they are rarely used in practice.

I don't have a specific C++ library in mind as a test case. I'm open to suggestions.

Thanks,

Liam

--
You received this message because you are subscribed to the Google Groups "dart-gsoc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dart-gsoc+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dart-gsoc/cc6dcb25-68bd-4336-8f24-bfeb694e286an%40googlegroups.com.