[GSoC 2026] C++ in FFIgen: Introduction and Questions

[Edward Alexandra]

Dear Liam and Brian,

My name is Edward Alexandra, and I'm applying to GSoC 2026 for the Dart project. I'm writing to introduce myself and share my interest in the C++ in FFIgen project.

I'm currently a student at Pelita Harapan University with experience in Dart and C++. I've built a working sample project that extends FFIgen's parsing pipeline to recognize C++ class declarations using libclang. Here's my approach:

• Created a new sub-parser (cppclassdecl_parser.dart) that walks CXCursor_ClassDecl children and extracts constructors, destructors, methods (including static/const detection), access specifiers, and fields
• Extended translation_unit_parser.dart to dispatch CXCursor_ClassDecl and CXCursor_Namespace cursor kinds
• Added clang_getCXXAccessSpecifier, clang_CXXMethod_isStatic, and clang_CXXMethod_isConst bindings to clang_bindings.dart
• Wrote a test that parses a sample C++ header and verifies the parser correctly identifies all class members

I can share this as secret gists if you'd like to review it.

Some questions I'd appreciate your input on:

1. For the C++ class AST node, should I create a new CppClass binding type (separate from the existing Struct/ObjCInterface), or would you prefer extending the existing Compound type? I noticed that Compound already handles struct/union members, but C++ classes have methods, constructors, and inheritance which are quite different.
2. When generating the extern "C" wrapper, should the C glue code go into a separate generated .cpp file that users compile alongside their project? Or is there a preferred build integration approach (e.g. using native_assets/build hooks)?

Thank you for your time. I look forward to working with you on this project!

Best regards,
Edward Alexandra
Github: ward-00

[Edward Alexandra]

Hi Liam and Brian,

Just wanted to follow up and share where things stand. I've made a lot of progress since my introduction and have submitted my proposal on the GSoC portal, including a link to the proposal draft and my sample project gist.

A quick summary of what's new since my first post:

For the sample project, I went a little further than just parsing. It now includes cppclassdecl_parser.dart modelled after the existing structdecl_parser.dart pattern, handles CXCursor_Namespace recursion, extracts access specifiers via clang_getCXXAccessSpecifier, detects static/const methods, and has a test that validates the output against a known C++ header. A few things I discovered along the way that weren't obvious from the docs: libclang needs -x c++ and -std=c++17 passed as compiler opts to parse C++ syntax correctly, and CXCursor_Namespace doesn't directly yield a declaration, you have to recurse into its children.

On the two questions from my earlier post, I've formed a view on both and written them up in the proposal, but I'd genuinely love your input:

1. For the AST node, I lean towards a new CppClass type rather than extending Compound, mainly because methods, constructors, and inheritance feel different enough that merging them would complicate the existing C/struct path. Happy to be convinced otherwise though.
2. For the C glue build integration — looking at the dart:ffi examples, build hooks via native_assets seem like the natural fit. Is that the direction you'd prefer, or is there a different approach already being considered for FFIgen?

The proposal also has a full feature priority table (P0 through P3) and a section on memory management patterns for unique_ptr, shared_ptr, and POD types. (Which is taken into considerations after reading mentor Liam's reply in another conversation) 

Thanks so much, and feel free to reach out if anything in the proposal needs clarification before the March 31st deadline!

Best,
Edward Alexandra

[Liam Appelbe]

Hi Edward

> For the AST node, I lean towards a new CppClass type rather than extending Compound, mainly because methods, constructors, and inheritance feel different enough that merging them would complicate the existing C/struct path. Happy to be convinced otherwise though.

Yeah, that's how I'd approach it too.

> For the C glue build integration — looking at the dart:ffi examples, build hooks via native_assets seem like the natural fit. Is that the direction you'd prefer, or is there a different approach already being considered for FFIgen?

You can just output a new .c file for now. This is how ObjC bindings work, outputting a .m file. My eventual plan is to also output a build hook script that will automatically build the .m file, so at that time we can also make sure it also compiles the generated .c file. I haven't had time to do that yet though, so for now just output the .m file.

For the sample code, if you put in a gist, it'll need to be a public gist. But don't put too much effort into the sample code before the main GSoC period starts. Overall your proposal looks great.

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/ed134d1a-366b-4890-9e22-40c41b5065e9n%40googlegroups.com.

[Edward Alexandra]

Hi Liam,

Thank you so much for taking the time to respond — this is really helpful!

Good to know the separate output file is the right approach for now. I'll model it after the ObjC .m output pattern and leave the build hook integration for when you get to it. I'll update my proposal to reflect this.

I'll also make the gist public as you suggested.

Thanks again, and looking forward to working with you if I'm accepted!

Best,
Edward