ComLightInterop

> I think Rust strikes a pretty good balance with it though I don’t like that balance. For performance-critical things like BLAS and other low-level numerical stuff, C++ is safer than unsafe Rust because standard library and tooling (debug heap, debug allocators, ASAN, etc.) evolved for decades making the language usable despite the unsafety. Another thing, for numerical code you probably need SIMD intrinsics. They were defined by Intel, documentation and other learning resources almost exclusively target C language; C++ got them for free due to compatibility. For high-level pieces which are not that performance critical, I use C#. Due to VM, it’s safer than Rust. Due to GC and other design choices usability is way better than Rust, e.g. in C# asynchronous I/O is almost trivial with async/await. The runtime is cross-platform, I have shipp

I do not recommend C++ CLI. Can you elaborate on why? I looked at various ways for interop between C# and C++ over the years, and overall found C++/CLI to be the best overall for our particular application types: it's a separate layer bewteen a C++ backend (which is also used in other non-gui applications), with a windows-only WPF desktop application on top. Mainly because the C++/CLI code itself is simple, readable and fairly effortless to write and maintain. A bit repetitive at times though, but that's going to be the case for any such layer AFAIK. Integration on the C# is seamless, with code completion etc, and C# interfaces can be implemented in C++/CLI directly for instance. The initial setup takes some work but with conversion between common types implemented (ability to e.g. IEnumerable<ManagedT> <-> std::vector<NativeT> or std::it

For requirements like that, I typically write WPF C# frontend, combined with C++ backend. Compared to ImGui, in WPF you’ll get a GUI designer, styling which allows easy dark mode, data bindings, data templates, animations, IDE support like live visual tree inspector, accessibility support, and more. If you use the legacy .NET 4 framework, the .NET runtime will come pre-installed on modern Windows. If you compile your C++ DLL with static C runtime, your C++ DLL won’t have any dependencies apart from OS components like kernel32.dll. If you insist on having a single EXE you’ll need to bundle it and extract, but the additional code for the P/Invoke to work is like 4 lines of that code, call LoadLibraryW from kernel32.dll early on startup, before using any stuff with [DllImport] from that DLL. I do not recommend C++ CLI. Write normal C++ which