Yomm2 VS Qt

More information about virtual_ptr is available in the documentation.

YOMM2 is available on GitHub.

And if you don't want to put a virtual function or have a base class, etc. check YOMM, which was recently mentioned in r/cpp.

I have a visitor themed example. I will update it to implement the visitor solution as well, for easier comparison.

the main README

I am publishing and documenting some of the internals of my YOMM2 library. I adopted the same style as cppreference.com. My library uses two constructs nested inside a class. cppreference documents template like this and their members like this. However, I use two constructs that are, AFAICT, not used in the standard library, so there is nothing for me to ape.

I don't know much of type theory, i'm just saying that i don't see when this could be useful in real life. On the other hand, multimethods such as what the Julia language has or, in C++, yomm2, sounds much more useful, as you can have two object *a, *b and calling f(a, b) will dispatch on the concrete type of all virtual arguments.

Qt mono repo : .. you could check out all submodules and simply use CMake to exactly achieve this. A mono repo also means that if I only use qtbase and declarative, I would need to have all submodules in there? - No

For e.g. if you’re writing a framework, you need to interface with Cocoa on MacOS to draw windows, which only provides an Objective C or Swift interface. You can look at the Qt source code and see how they do it: https://github.com/qt/qtbase/tree/067b53864112c084587fa9a507eb4bde3d50a6e1/src/plugins/platforms/cocoa

That's because Qt 6 wholeheartedly converted to CMake for you. (At least it is better than qmake.) In order to support this Qt has this large battery of CMake files [1]. Qt is of course a clear outlier, but you can't expect the same level of support from every other library you want. My points about "anything exotic" still stand.

[1] https://github.com/qt/qtbase/tree/dev/cmake

What are you talking about? Qt has GTK theme support built-in: https://github.com/qt/qtbase/tree/dev/src/plugins/platformthemes/gtk3

This looks like the Qt bug solved by this commit: https://github.com/qt/qtbase/commit/acaabc9108dfe75530960cf8e3ec4f3602cd82e0

Yeah, I'm sure it's completely unheard of. Oh except that it took me all of a couple minutes to find an example of that exact thing in one of the largest, most commonly used C++ frameworks out there.

I don't see any connect in https://github.com/qt/qtbase/blob/dev/src/corelib/tools/qsharedpointer_impl.h, and QPointer isn't a QObject (though I don't know if the latter is actually necessary for signal-slots). One (unreliable) way to test is to see if a QPointer fails to be nulled out when the QObject is blocked by a QSignalBlocker. Alternatively I'd set a data breakpoint on a QPointer and try it out. But I don't have the time right now.