ComLightInterop VS Rocket

I have once made something remotely similar, to interop between C++ and C#: https://github.com/Const-me/ComLightInterop

I took different approach. Because I only needed to support these two languages, there’s no separate interface definition language, and no code generator for interfaces. Instead, users are expected to write both language projections manually.

Then there’s a runtime code generator on the .NET side of the interop which builds runtime callable proxy types for interfaces implemented in C++, also virtual tables for C# objects consumed by C++.

It’s pretty fast. Likely reason for that, MS designed both language and runtime this way since version 1.0. They needed that for their Windows Forms which consumes huge chunk of WinAPI.

I benchmarked a while ago when testing this library https://github.com/Const-me/ComLightInterop#performance On the computer I was using at that time (probably Ryzen 5 3600 CPU) the overhead was 15-20 nanoseconds per call.

That thing is COM, which is a small subset of C++ ABI. Technically it’s about the same as on Windows, i.e. C ABI with extra first argument for this pointer.

Once upon a time I made this library https://github.com/const-me/comlightInterop/ The native side of the interop is idiomatic C++, here’s an example https://github.com/Const-me/ComLightInterop/blob/master/Demo... The C# side of the interop is implemented through the built-in C interop, here’s the relevant part of the library https://github.com/Const-me/ComLightInterop/blob/master/ComL... I’ve tested Linux version of that library on AMD64, ARMv7, and ARM64 CPUs, but only with gcc compiler on the native side.

I like many parts of COM, but I believe that example mostly demonstrates bad parts, with IDL, registrations, and over-engineered support libraries.

There's nothing wrong with exporting factory functions from DLLs. Microsoft does it all the time, APIs like Direct3D, DirectDraw and Media Foundation don't come with type libraries are they aren't registered anywhere.

Speaking about support libraries, I once made my own: https://github.com/Const-me/ComLightInterop/tree/master/ComL... Compare examples from that article with this one: https://github.com/Const-me/ComLightInterop/blob/master/Demo... That source file is the complete DLL which implements a minimalistic COM object.

> Does it feel "brittle" to use

Yes and no.

No because when you try to do unsupported things like calling a method on an object which doesn’t support one, you gonna get an appropriate runtime exception.

Yes because if you fail lower-level things like local parameter allocation, you gonna get an appropriate runtime exception but that one is (1) too late, I’d prefer such things to be detected when you emit the code, not when trying to use the generated code (2) Lacks the context.

Overall, when I can I’m using that higher-level System.Linq.Expressions for runtime codegen. Things are much nicer at that level. I only using the low-level thing when I need to emit new types, like there: https://github.com/Const-me/ComLightInterop/blob/master/ComL...

> Do you have any good resources on writing dlls to consume via .net like you’re talking about?

For C APIs i.e. functions, structures and strings, the good resource is Microsoft documentation, the support is built-in, see “Consuming Unmanaged DLL Functions” section: https://docs.microsoft.com/en-us/dotnet/framework/interop/

For COM APIs i.e. sharing objects around see this library + demos: https://github.com/Const-me/ComLightInterop It’s only really needed on Linux because the desktop version of the framework has COM support already built-in, but it can be used for cross-platform things just fine, I tested that quite well i.e. not just with these simple demos.

> How do you deal with the managed memory when using the gc from .net

Most of the time, automatically.

When you calling C++ from C#, the runtime automatically pins arguments like strings or arrays. Pinning means until the C++ function returns, .NET GC won’t touch these things. This doesn’t normally make any copies: C++ will receive raw pointers/native references to the .NET objects.

Sometimes you do want to retain C# objects from C++ or vice versa i.e. keep them alive after the function/method returns. An idiomatic solution for these use cases is COM interop. IUnknown interface (a base interface for the rest of COM interfaces) allows to retain/release things across languages.

C++ interop is not supported in modern .NET out of the box, but wasn't too hard to implement as a library: https://github.com/Const-me/ComLightInterop

At the bottom of the Rocket web site there are a few sponsors listed Kindness.ai, ohne Makler, 1Password, Signal Insight, and Edwin Olback. There are more sponsors on GitHub sponsors page

4. Rocket

If you want something simpler/more minimal, you could use https://rocket.rs/ for the backend and handle the front-end however you want.

I’m the author of https://kellnr.io. When I started working on Kellnr three years ago, https://rocket.rs was “the web framework” to use. Unfortunately, the project seems dead. Before adding more functionality using an unmaintained framework, I want to port Kellnr to https://github.com/tokio-rs/axum.

Or else you could of course just use https://rocket.rs/

Rust is a popular system programming language, known for its robust memory safety features and exceptional performance. While Rust was originally a system programming language, its application has evolved. Now you can see Rust in different app platforms, mobile apps, and of course, in web apps — both in the frontend and backend, with frameworks like Rocket, Axum, and Actix making it even easier to build web applications with Rust.

I've done some research but I have to admit that creating embedded devices is a totally new subject for me, but that is the point of the project - main goal is learning, and creating something is the secondary goal, so please bear with me and my knowledge of the subject. So, for the hardware I've seen many people recommending SMT32 family devices, but I've also read that anything with the Cortex-M processor can be suitable. Need more info on that. OS is a hard choice for me because on one hand I was thinking of Ubuntu Core but the device support is not really that good I think, so other options I've found are Tock and RIOT-OS, and I am gravitating towards the latter because it's main focus is on IOT devices. I've found frameworks like Rocket.rs for a web app, tauri.app for desktop app (which might not be needed but I still like the idea). Also found Tokio.rs which apparently will help with the networking. There was a discussion from the other members about using the Golioth cloud platform with Zephyr and C++, and I don't know if there are any other alternatives for Golioth that support Rust, I've found webthings.io but I am not sure if it's an alternative, or something else actually, so I would be happy to learn more about that. Again I want to hear your recommendations regarding anything that will help creating a project like that.