Linked by Thom Holwerda on Tue 21st Sep 2010 21:32 UTC, submitted by diegocg
Permalink for comment 442545
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/18/13 21:06 UTC
Linked by Thom Holwerda on 05/18/13 7:37 UTC
Linked by fran on 05/18/13 1:38 UTC
Linked by Thom Holwerda on 05/17/13 23:35 UTC, submitted by kragil
Linked by MOS6510 on 05/17/13 22:22 UTC
Linked by Thom Holwerda on 05/17/13 22:15 UTC, submitted by Tom
Linked by Thom Holwerda on 05/16/13 21:41 UTC
Linked by Thom Holwerda on 05/16/13 17:04 UTC
Linked by Thom Holwerda on 05/16/13 13:17 UTC
Linked by Thom Holwerda on 05/16/13 12:06 UTC
More News »
Sponsored Links



Member since:
2005-07-22
From a practical point of view, what you say is impossible. No one is going to write the huge boilerplate code required for Qt to work manually.
So, Qt actually requires using the MOC. "
It is quite straightforward to create everything the moc creates at runtime.
For instance, the qml environment creates QMetaObjects at runtime, as do most of the Qt language bindings. All the moc mostly does is generate code for QMetaObjects, and so you can do everything the moc does at runtime pretty much.
If qt was basic on statically typed signals and slots like Boost signals, then you wouldn't be able to do that sort of thing. Which would be a big loss. Nor would KDE KParts work and a lot of other features which depend on the *dynamic* runtime that the moc based features of Qt provide.