| |||||||||||||
Qt 5.0 releasedQt 5.0 releasedPosted Dec 20, 2012 14:36 UTC (Thu) by krake (subscriber, #55996)In reply to: Qt 5.0 released by rleigh Parent article: Qt 5.0 released
"It would be nice if it could be taken all the way, though."
I am not sure what you mean with "all the way" as the new connect() options are fully compile time based.
One of the advantages of the now additional runtime checked option is that it does not require information on the concrete types of sender or receiver, while still keeping type-safety for signal/slot arguments.
"The other issue when integrating into a wider non-Qt project is that Qt-using code is no longer strictly C++: It's a Qt dialect which is processed into C++ at build time (I'm referring to the slots: syntax etc)."
No, this is handled by the compiler itself, or rather its preprocessor. A Qt file is a standard C++ header or source file, as can easily be verified by running a C++ compiler on it manually. Same is of course true for the file generated by moc.
It would have been an unmanagable situtation for Trolltech to deliver a custom compiler for all platforms they supported.
(Log in to post comments)
Qt 5.0 released Posted Dec 20, 2012 14:58 UTC (Thu) by rleigh (subscriber, #14622) [Link]
> I am not sure what you mean with "all the way" as the new connect()
> options are fully compile time based.
I'm referring to the other half of the problem, the slot definitions. Such as boost::signal<> or sigc::signal<>, both of which allow slot definition without requiring any special syntax or tool support.
> No, this is handled by the compiler itself, or rather its preprocessor. A
Oh, certainly. I'm not arguing with how it's implemented--in the preprocessor--, just that it does effectively make Qt-using sources a non-standard C++ dialect as a result.
> It would have been an unmanagable situtation for Trolltech to deliver a
Sure, I understand the historical reasons, and they make perfect sense in this context. But all the other signal/slot mechanisms such as sigc++ and boost::signals require nothing except compiler template support, which all compilers have supported for well over a decade now. It does seem a little odd, in 2012, not to rely on the standard library and facilities like this where it makes a lot of sense.
Regards,
Qt 5.0 released Posted Dec 20, 2012 15:27 UTC (Thu) by krake (subscriber, #55996) [Link]
> I'm referring to the other half of the problem, the slot definitions.
You need those for the traditional variant of connect.
Are you saying that the two markup alternatives you mentioned can provide the necessary introspection data for runtime checked connect on base class pointers?
Otherwise I am a bit puzzled considering the compile time checked variants of connect seemed what you would be going for.
> just that it does effectively make Qt-using sources a non-standard C++ dialect as a result.
Hmm, I am afraid I can't follow you here either.
Or are you saying any form of preprocessor substitution makes something non-standard C++? How does on solve includes and include guard using standard C++?
> Sure, I understand the historical reasons, and they make perfect sense in this context.
You must have put this sentence into a wrong line by accident, since it does make not sense in the context of the quoted line.
Not relying on a custom compiler for every platform does still make perfect sense in present context.
That's why Qt code has not, does not and almost certainly will not require a custom C++ compiler but will continue to work with the compilers that compiler or platform vendors release.
> But all the other signal/slot mechanisms such as sigc++ and
I wasn't aware that those libraries provide runtime connect based on introspection of base class pointers.
Qt 5.0 released Posted Dec 22, 2012 18:27 UTC (Sat) by rleigh (subscriber, #14622) [Link]
While the libsigc++ and Booost style slot equivalents don't directly support introspection (they are just class members), you could layer that on top easily enough without needing an external tool to do so; though I'm not familiar enough with the internals of moc to know if that could be done compatibly or not WRT the signature extraction. You'd probably still need some preprocessor support to register and define the slot in a single statement.
Regarding the C++ dialect issues--I think we're talking at cross-purposes here; I don't think we're in disagreement, just misunderstanding.
Regards,
|
|||||||||||||