ipr VS verdigris

I'm not sure about clang or gcc. For VS, u/GabrielDosReis might be able to speak to the .ifc IPR stability/volatility. My wager (deferring to him to correct me) is that the IPR is still changing over time but will stabilize more over time.

Have you had a look at its uses in the IPR interface and implementation? https://github.com/GabrielDosReis/ipr/blob/main/include/ipr/interface

> C++ has virtually zero tooling

CMake, Meson, Waf, Conan, Visual Studio Code, Visual Studio, CLion, Intel VTune, GDB, LLDB, XCode, Artifactory, SonarQube, clang-tidy, clang-format, astyle, Incredibuild...

> Comparing CMake to cargo is like comparing fifth century fireworks to the Space Shuttle

You are wrong here. Cargo serves a set of fixed "this-is-how-to-do-it" thing. In C++ you can build anything. I do not mean it is better, but C++ software already exists and that is the solution that it works better for it. :)

> and the committee is not interested in ever working on that

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p08...

Interoperability effort for modules: https://github.com/GabrielDosReis/ipr

IPR Library

This is overly dramatic. The "keywords" are just macros. If you don't want an additional preprocessor to generate code in a separate .cpp file from these macros, you can use https://github.com/woboq/verdigris

The concurrency model, object ownership and life cycle you are mentioning are not part of C++, those are just conventions in specific C++ user groups - Qt code compiles plain and simple with pretty much every conformant C++ compiler and that makes it as much C++ as anything else.

There were a couple of attempts in that direction, but i haven't really seen them used in any production codebase.

https://woboq.com/blog/verdigris-qt-without-moc.html

Is Moc for signals and slots still needed? Mind you, I haven't used Qt in 15 years, but I was sure I heard about some standard C++ way of building Qt apps without needing the MOC prebuild step (IIRC https://woboq.com/blog/verdigris-qt-without-moc.html).

Nope, Qt 6 still uses moc. I don't think modern C++ meta programming is quite capable of entirely replacing moc. The closest thing I'm aware of is [0], but it requires additional macros compared to what moc requires, and compilation speed can suffer. Chances are moc won't be dropped until full reflection lands, if ever, and even then if compilation speed is too bad I wouldn't be entirely surprised if moc remains.

[0]: https://github.com/woboq/verdigris

Verdigris

`QML_ELEMENT` support for Verdigris. https://github.com/woboq/verdigris/pull/99

> it's possible to do Qt without moc even in C++ with https://github.com/woboq/verdigris/, why wouldn't it be possible from D ?

You're talking about an entirely different thing. While OP was referring to the current state of D's ecosystem and the impact that missing key frameworks have on hindering adoption, you're arguing about the theoretical possibility of writing a framework with a language, which really does not address OP's point.

And much more importantly, MOC specifically is a code generator which has a competitor without the code generation requirement. Fully compatible even. So no, sorry "Qt is bad because MOC" stopped being an argument years ago (if it ever was).

But copperspice is not a better version: see the benchmark here: https://woboq.com/blog/verdigris-qt-without-moc.html