Why do you hate the MOC?

[ghost]

Qt's MOC is not something that bad. CopperSpice replaced it with heavy macros and templates that caused the compilation to be very slow and taking more computer resources. The produced binary is also more bloated in size and slower at runtime.

Take a look at this article:

https://woboq.com/blog/moc-myths.html

Based on what you wrote on your website, it seems you are in the same camp as the CopperSpice developers, thinking that the MOC is bad and needs to be removed.

[RolandHughes]

An opinion shared by most of the programming world, at least the world that has gone to college for a degree in Computer Science.

Note that woboq.com is where Qt hosts source code. You can find it referenced many times in the qt_interest archives.

So, when you see something like "moc-myths" posted there it was most likely written by someone at Qtc.

Compilation is definitely more resource intensive, but MOC left landmines. I've had customers that lost entire staff days tracking down inexplicable bugs caused by stale MOC artifacts.

Please note this:
When writing Qt code, you are not writing real C++

Is actually true for 80+ percent of "Qt developers" because they are writing QML which is JavaScript derived, not C++.

The run-time thing is also BS. CopperSpice is slow because they ripped out CoW (Copy on Write). This was a choice of academic purity so the library could use exceptions. (While you will find mentions of using exceptions with Qt on the qt-interest list, you will also find that Qt does not allow exceptions.) I've know about this for a long time.

https://www.logikalsolutions.com/wordpress/information-technology/qlist/

It's fixable and on the list of things to be fixed. No, I'm not bringing back CoW. You can get an exceptions compatible string class that only copies when needed by creating a wrapper class. On assignment you use a string view and when only becomes a real string when it needs to.

MOC was coal for the steam engine era. (Most of the world doesn't use coal anymore.) It comes from the era of OS/2, the 286 processor, and C++ before there were much in the way of standards. Borland C++ rolled its own as did most compiler vendors. Like coal, MOC was a necessary evil to achieve a goal, just wasn't good for the ecosystem though.

Under DOS and GUI DOS (Windows prior to NT) we had a 640K memory limit. The 384K above that, known as the "memory hole" was for add-in cards and adapters. Most notably your video card. We then had various "loadhi" utilities that would guess what memory was addressable to stuff device drivers in. They would always guess wrong because at boot you were running in basic text VGA mode. When you loaded graphics, like a game, the video card use a lot more of that 384K, walking on your drivers.

One of the contributors is using a 4th gen CPU. They build this thing as-is in about 3 or 3.5 hours. Not unreasonable given the vintage of the equipment, and still doable. One would be lucky to get more than $30 for a pre-4th gen Intel machine today. Keep in mind they are not only building the libraries but also generating two (2) Debian packages with that script.

Purging the bundled Harfbuz, Webkit, JavaScript, etc. and relying on platform provided packages will dramatically reduce the build times.

About 10 years ago I had to work on a medical device that had only 512MB of RAM and no GPU. We had to pre-load all of the images and BLIT them onto the screen. (Hence the BLIT option on the roadmap.)