Rust and C++ Interoperability

https://slint-ui.com/blog/rust-and-cpp.html

by ogoffart • 4 years ago

235 77 4 years ago

Does anyone have experience using Slint do develop GUI in Rust?

GUI in Rust is a hot topic, and to me it seems SlintUI may be the best general-purpose so far. The reason is rapid iteration and a flexible/intuitive layout system: Slint lets you write UI in a DSL with live preview and style/layout influenced by HTML and CSS, whereas competitors (egui, druid, iced) require you to write the GUI in Rust (which means you must rebuild and rerun to see changes) and have their own style/layout rules. Other competitors are GTK and Qt, but those have their own flaws and moreover, were designed way before Rust and seem to be less "idiomatic".

dilawar• 4 years ago

We are developing UI in slint-rs for our product. Our eventiual target is IoT devices (cyber defense) though we are starting with desktops. We are a young startup and our experience is very limited in UI space so please take all of it with a pinch of salt.

One of our intern got the UI working with Slint in a few days and since then we didn't feel a strong need to move away from it. We found a few missing features: it was not possible to tell if a Windows is hidden or not. We ended up sending a few patches.

So far our experience has been pretty good with slint-ui. We are not tested the UI on OSX and Linux yet, only windows. On AWS machines with Windows server, the UI fails to launch sometimes because of some missing GL libraries. Also note the licensing of Slint-UI https://github.com/slint-ui/slint/discussions/379.

Herbstluft• 4 years ago

Wow that linked request is really something. Requesting/Suggesting the change of license is one thing. But this is just another example of a blatant lack of respect towards open source devs and maintainers.

The misinformed GPL hatred displayed there is also ridiculous.

gattr• 4 years ago

I use GTK3 with Rust for my video acquisition tool [1] and it's been quite pleasant so far. However, from my testing GTK3 & 4 don't play nice with OpenGL drawing areas, so the next project I'm writing (also in Rust) using Dear ImGUI.

[1] https://github.com/GreatAttractor/vidoxide

not2b2• 4 years ago

"The situation on the C++ side isn't too different: The ABI is compiler defined. This is why you can not mix libraries generated with MSVC and GCC."

There is a multi-vendor C++ ABI, honored by clang, GCC, Intel's proprietary compiler, and others. It doesn't solve all problems, but provides interoperability.

dataflow10• 4 years ago

I never got why ABI incompatibility is such a big problem. Why does every non-Windows compiler insist on bringing a non-Windows ABI to Windows? Why can't people just respect whatever the convention on each platform is and move on? It's not like you need ABIs to be cross-compatible across platforms.

fsloth• 4 years ago

I suppose the key reason is ABI is not defined by the language standard? Nor is it is something (AFAIK) that would be standardized on Windows. This is not the same thing as binary compatibility on windows but rather about the internals of virtual function tables and so on.

There are other problems as well from the "hands off" quality of the standard.

Endemic of how bad the situation is regarding C++ DLL:s is that you can't free memory in a different C++ DLL than where it was allocated. Well, you _can_ but most of the time you shouldn't.

chrisseaton• 4 years ago

Why does every non-Windows compiler insist on bringing a non-Windows ABI to Windows?

Isn't the point of a using a different compiler to let it compile your code in different ways? Having to meet an arbitrary ABI is a limiting restriction you may not want.

bpye2• 4 years ago

LLVM/Clang does mostly support the MSVC C++ ABI today - https://clang.llvm.org/docs/MSVCCompatibility.html . I've not used it for anything major but in my limited experience it does work. Native PDB generation also makes debug much more pleasant with tools like WinDbg.

formerly_proven• 4 years ago

It took Microsoft a pretty long time to settle on one C++ ABI. Until then, every major MSVC version had its own, incompatible C++ ABI - no "Windows ABI".

ordu• 4 years ago

It's a long tradition of Windows to have some weird ABI. Even before C++ Windows API used "pascal calling convention". And then MS probably intentionally made it difficult to follow their C++ ABI to shun away all other compilers from their platform. They did a lot of this at the time.

snarfy• 4 years ago

The main problem is it came about 20 years too late. Anybody writing libraries in C++ today either use C linkage or ship multiple versions.

pjmlp6• 4 years ago

Third option, we use COM.

codeflo• 4 years ago

I'd say this is misleading, or only technically correct (the best kind of correct). Calling conventions are only the first step. For interop to be useful in practice -- to be able pass more interesting C++ types than integers -- you also need your standard library types to be (and remain) compatible[1]. This currently isn't guaranteed even across versions of the same compiler.

[1] Herb Sutter's C++ ABI effort was supposed to solve exactly this, but unfortunately never went anywhere. The proposal document pinpoints the problem very well in my opinion: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n40...

rossmohax• 4 years ago

Do you have exmoles to support claim that there is no compatibility between versions of the same compiler? your linked pdf is from 2014, exact time when compilers stopped breaking things.

AFAIK MSVC compilers explicitly guarantee ABI compatibility since 2015 https://learn.microsoft.com/en-us/cpp/porting/binary-compat-...

as for other platforms, all compilers adhere to Itanium ABI and didnt introduce breaking changes for many years now. Standard libraries, libc++ has explicit ABI guarantee as well (https://libcxx.llvm.org/DesignDocs/ABIVersioning.html).

Libstdc++ uses symbol versioning and only nasty thing happened to it was problem with std::string CoW decade ago, but even that was done neatly and in compatible manner https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_a...

gpderetta4• 4 years ago

Because the C++ ABI is fragile, in practice you need a blessed library ABI for the standard library. On linux for example it is libstdc++ which has been stable for almost 20 years (yes, there was a brakeage around c++11, but there are compatible shims for backward compat). Clang and the intel compiler can compile against libstdc++.

zozbot2344• 4 years ago

This blogpost should really mention the autocxx and crubit crates. There's a lot more to Rust/C++ interop than what they cover, and work on it is very much ongoing.

kolbe• 4 years ago

I think the link time optimization work is amazing as well. Calling out to different languages can really suck without whole program optimization, even if both the rust and the c++ sides are fully optimized, but taking the LLVM bit code of each and then running optimizations those bridges that gap.

eco• 4 years ago

Great article. Answered a lot of questions I've had as I toy with the idea of making part of a C++ project in Rust.

Regarding Slint and all the other new GUI toolkits, one thing I don't understand is why they all seem to completely ignore any controls more complicated than the basics (buttons, checkboxes, drop downs, spin controls, sliders, radio buttons, and a basic list control).

A To-Do app is a proof of concept, not an endgame.

Beyond those basics I need combo boxes, date time pickers, color pickers, font pickers (fonts are hard, I get it, but my users expect access to system fonts), dockable windows, splits, tabs, modal dialogs, tooltips, masked text input, auto completion text input, context menus, calendar controls, file and directory pickers.

Some of the new toolkits offer an assortment of these, including Slint but they rarely get all of them but the biggest thing missing from pretty much all of them are sophisticated data grids (both list and tree varieties). They need support for custom cell rendering, custom cell edit controls, and variable row heights. They also need to be fast even with tens of thousands of rows.

Oh, and think about your printing story. You don't print a UI obviously but if I'm rendering diagrams and stuff using your rendering facilities I at least need a way to hook them up to the platform's system without just duplicating all of the drawing to a completely different rendering API to make printing work.

This isn't a dig on Slint. I'm eagerly watching it, along with egui, as I desperately look for a cross platform alternative to all the legacy stuff I'm neck deep in. I just can't consider anything that has no good support for data dense applications.

antihero• 4 years ago

I think one of the issues with going beyond the basics is that once you start to tackle more advanced controls you not only have to be more opinionated, as there’s many ways to achieve these things, but also they become for more specific use cases and thus creating a general solution has exponential complexity.

zarzavat• 4 years ago

What people want from a UI library is to be able to use system components. For example, there should be a way to open the system color picker, to display a system data grid, system date picker, etc. It doesn’t need to be more than that.

friendzis• 4 years ago

Qt has solved this problem in a pretty neat way

bruce343434• 4 years ago

If you have combo boxes then you already have a font picker. Do you mean you want a built in way to enumerate installed fonts?

edit: I realized that you want the menu entries to be rendered in the fonts themselves

alkonaut• 4 years ago

Any combo box with custom draw functionality will provide that.

chrismanning• 4 years ago

It may be worth looking at qmetaobject[0] which lets you use Qt/QML from Rust. Whatever you can do in QML you can do with qmetaobject, and writing new Qt stuff can be done with some annotated Rust code. I'm using it in a personal project and quite enjoying it, the lack of C++ tooling is a joy not to be understated. I believe it's from the same author as Slint.

[0] https://crates.io/crates/qmetaobject

b20000• 4 years ago

TLDR use a robust c++ toolkit like QT and spend more time on what matters.

harryjadon• 4 years ago

Great article. Answered a lot of questions I've had as I toy with the idea of making part of a C++ project in Rust.

booleandilemma• 4 years ago

Your comment is worded exactly the same way as this person's comment: https://news.ycombinator.com/item?id=33591111

Are you the same person? I'm just curious. It's a funny coincidence :)

virtualritz• 4 years ago

This seems to miss `cppmm` (C++--)[1].

This crate is currently mainly aimed at helping people from the Rust group of the Academy Software Foundation (ASWF) to make wrappers for the visual effects ecosystem of libs.[2]

It is nevertheless very useful for all types of other cases.

[1] https://github.com/vfx-rs/cppmm

[2] The above just means effort is prioritized regarding the blockers these libs present due to the resp. C++ features they use.

zozbot2344• 4 years ago

Great, so now we have cxx, autocxx, crubit and cppmm. The Rust folks should convene an actual Working Group on this issue, there's clearly a lot of demand for a solution.

tobias123452• 4 years ago

The problem is that the different crates typically address certain sub-eco-systems and produce better results for that one dialekt spoken there. It is hard to generalize all that.

tobias123452• 4 years ago

I missed more: There are a lot of tools out there addressing special cases. Those typically address certain C++ sub-eco-systems that follow certain rules that make the mapping in some special cases better.

Most of these are either built on top of cxx or are similar in spirit. So I did not list all of them. The original presentation was only 30 min and there is only so much you can ask a person to read in a blog post:-)

I did try to make it clear that my list is in no way exhaustive.

mkoubaa• 4 years ago

The carbon project for c++ defines some fixed ABI types in the standard library to enable things like this. I hope that c++ can learn from that - I tried to propose fixed ABI types in the standard a few years back but didn't get very far

rajman187• 4 years ago

I have used CXX in a project where I had to use a library available only in C++. There were Python bindings but somehow they were very slow. I could have rolled out my own pybind11 but wanted some of the Rust guarantees.

It was probably more convoluted than necessary since I also then exposed the Rust lib to Python, so C++ <=> Rust <=> Python , but it was indeed fun to implement it all.

https://github.com/dtolnay/cxx

htfy96• 4 years ago

There's also a more blasphemy-ish approach of interop between C++ and Rust if the C++ code already have good Python bindings: C++ <=> Python <=> Rust. It's not bad as you may think. My company uses it to adapt C++ to Rust without rewriting the 40K LOC Pybind11 boilerplate. Going through the Python interpreter is definitely slower than a native call but perhaps <3x since we only rely on Python being a hosted + GC environment, plus it's much easier to express lifetime in Rust given that everything is managed on Python heap.

hda2• 4 years ago

I really hope one of these approaches gets bundled with the official (or gcc) toolchain one day. C++ is widespread enough that it should be supported directly like C and not require downloading yet another deptree from crates.io.

Rust and C++ Interoperability

Related Stories