-
Notifications
You must be signed in to change notification settings - Fork 162
Description
Hi, thanks for the great work on autocxx — it’s been instrumental in reducing C++/Rust FFI boilerplate.
I’d like to propose a feature to extend autocxx to generate Microsoft proxy (v4) facades, enabling seamless integration with modern C++ dynamic polymorphism and dependency injection (DI) patterns.
🎯 Motivation
Many large-scale C++ codebases (e.g.,HPC middleware) are adopting:
- Microsoft
proxyv4 for zero-overhead dynamic dispatch, facade composition, and DI-friendly design (e.g.,pro::v4::proxy<IMyService>). - Rust for performance-critical kernels (e.g., geometry processing, spatial indexing), with C++ as the integration layer (UI, DI, callbacks).
Current workflow requires manual:
- Writing
cxxbridges for each method - Hand-coding
proxyinterface + bridge class - Managing DI registration separately
This reintroduces error-prone duplication and hinders maintainability.
✨ Proposed Solution
Add opt-in support to generate proxy-compatible artifacts from C++ interface declarations:
Input (C++)
// In some header
#include <proxy.h>
PROXY_INTERFACE(IMyService) {
virtual std::vector<uint8_t> process(std::span) = 0;
};
Desired autocxx Output
- ✅ Rust trait (for implementation):
#[cxx::bridge] mod ffi { unsafe extern "C++" { include!("my_service.h"); type IMyService; } } trait MyService { fn process(&self, &[u8]) -> Vec<u8>; }
- 📦 So that we can use a service implemented by rust in c++ side
// autocxx_gen/my_service.proxy.h
struct MyServiceBridge final : IMyService {
rust::Box<MyServiceImpl> impl_; // ← held Rust impl
std::vector<uint8_t> process(std::span<const uint8_t> data) override;
};
extern "C" IMyService* autocxx_create_my_service();✅ DI registration hook (e.g., for facade_builder or custom containers)
🔧 Design Considerations
Zero-copy: Use std::span ↔ &[u8] where possible (already supported via cxx’s CxxVector + custom typemaps).
Ownership: Prefer rust::Box for Rust-side impl lifetime tied to proxy.
Opt-in: Controlled by #[autocxx::proxy] attribute or config flag (e.g., autocxx_integration::Config::enable_proxy(true)).
Compatibility: Target proxy v4.x (current stable); avoid v3 legacy.
📦 Use Case Alignment
This would directly enable:
Rust-native performance kernels (e.g., rbush, kdbush, zarr processing)
C++-hosted DI graphs (e.g., Microsoft.Extensions.DependencyInjection, custom facade_builder)
Dual-stack architectures with single-source-of-truth interface definitions
🙏 Would this fit autocxx’s scope?
If yes, I’m happy to contribute a prototype (e.g., extend autocxx-gen with a ProxyGenerator pass). Let me know if you’d like a design sketch or PoC.
Thanks for considering!