undefined | Better HN

0 pointsstinos1y ago0 comments

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::iterator<NativeT> etc) it's all pleasant and good.

or check this library of mine https://github.com/Const-me/ComLightInterop/

Gotta say this looks neat, but it's exactly the type of code I'd rather not write: UUIDs, bunch of macros, unclear mapping between return types (HRESULT vs bool), having to declare same interfaces both in C++ and C#, ...

0 comments

1 comments · 1 top-level

Const-me1y ago

> Can you elaborate on why?

The language is only supported in a single compiler, and is specific to Windows.

The language is based on both C++ and .NET runtimes, and when I used it (admittedly, it was many years ago) I didn’t like the usability consequences. These two runtimes interact in a weird way. It’s hard to compose data structures which contain both managed and unmanaged pieces, see that question https://stackoverflow.com/q/10523268/126995 You can’t include Windows SDK headers in CLI code, not gonna compile: https://stackoverflow.com/q/26502283/126995 Same applies to most third-party C and C++ libraries.

So with CLI you have 3 languages instead of just two: C#, C++/CLI, and classic C++.

> it's exactly the type of code I'd rather not write

I have used that library in multiple projects in the last 5 years, for Windows and Linux platforms including ARM Linux, both open source and commercial. It worked great for my use cases.

Here’s an open-source example of a relatively complicated COM interface implemented on top of ComLightInterop. C# interface: https://github.com/Const-me/Cgml/blob/master/CGML/CgmlNet/iC... C++ interface: https://github.com/Const-me/Cgml/blob/master/CGML/Cgml/API/i... C++ implementation: https://github.com/Const-me/Cgml/blob/master/CGML/Cgml/D3D/C...

As you see it has very few macros, no bool returning methods, very clean API between managed and unmanaged parts, and most importantly very readable idiomatic codes on both sides of the interop.

I’d like to add that if you make mistakes when writing these C++ and C# projection of a COM interface you’ll find very soon because it’s likely to crash on first use due to /GS compiler switch. Also trivial to debug and fix because VS supports mixed-mode debugging.

j / k navigate · click thread line to collapse