Linked by Thom Holwerda on Tue 21st Sep 2010 21:32 UTC, submitted by diegocg
Qt After many months of designing, coding, reviewing, testing and documenting, Qt 4.7.0 is finally ready for the big time. Although it's a little more than nine months since Qt's last feature release (4.6.0 on December 1, 2009), the seeds of some of the new stuff in 4.7 were sown much earlier. Indeed, many of the ideas behind the biggest new feature in Qt 4.7.0, Qt Quick, were born more than two years ago, not long after Qt 4.4 was released
Thread beginning with comment 442536
To view parent comment, click here.
To read all comments associated with this story, please click here.
axilmar
Member since:
2006-03-20

As I already have written, you do not have to use MOC. Nothing stops you from manually write the pure C++ code that MOC generates.


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.

Reply Parent Score: 2

Richard Dale Member since:
2005-07-22

"As I already have written, you do not have to use MOC. Nothing stops you from manually write the pure C++ code that MOC generates.


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.

Reply Parent Score: 2

axilmar Member since:
2006-03-20

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.


Oh yeah? please show me the relevant Qt documentation that allows one to do the same job himself.

(psst...don't bother, there is no documentation. Qt does not encourage that, and I don't want to have to support many versions of the Qt internals that might change from version to version).

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.


There is nothing that stops a statically typed signals and slots system to be connected at runtime via text files. All that is required is the appropriate interfaces in the code.

Reply Parent Score: 2

_txf_ Member since:
2008-03-17

Stick to making console apps. It seems to me that you want the impossible.

Reply Parent Score: 2