| |||||||||||||
Qt 5.0 releasedQt 5.0 releasedPosted Dec 19, 2012 19:58 UTC (Wed) by rleigh (subscriber, #14622)In reply to: Qt 5.0 released by Kit Parent article: Qt 5.0 released
The fact that you can now directly connect signal handlers without using moc to generate them is great. I vastly prefer this form from previously using libsigc++ and boost::signal; it's nice to see Qt getting the same type-safe handler style, and even nicer to see that you can use C++11 lambdas! I hated runtime exceptions when the signatures don't match, since it's entirely possible to catch this at compile time!
I assume you still need moc for SLOTs though, which if true is a shame. It would be nice to remove the need for moc entirely (or as much as is possible).
The other feature of note for me is the OpenGL work. Can anyone confirm if it's possible to build Qt to run directly on the framebuffer with a modern DRI2/KVM setup with accelereted GL? Or is X or wayland a hard requirement?
(Log in to post comments)
Qt 5.0 released Posted Dec 19, 2012 20:14 UTC (Wed) by HelloWorld (guest, #56129) [Link]
> I assume you still need moc for SLOTs though, which if true is a shame. It would be nice to remove the need for moc entirely (or as much as is possible).
moc will never go away as it does more than signals and slots nowadays. Basically it adds the stuff that Objective-C has and that C++ is missing: introspection, properties and probably more.
> The other feature of note for me is the OpenGL work. Can anyone confirm if it's possible to build Qt to run directly on the framebuffer with a modern DRI2/KVM setup with accelereted GL? Or is X or wayland a hard requirement?
Qt 5.0 released Posted Dec 20, 2012 9:44 UTC (Thu) by nazgulos (subscriber, #66348) [Link]
> I assume you still need moc for SLOTs though, which if true is a shame. It would be nice to remove the need for moc entirely (or as much as is possible).
Why moc is so bad? Do you hate others code generators, or just generated code?
Qt 5.0 released Posted Dec 20, 2012 11:50 UTC (Thu) by rleigh (subscriber, #14622) [Link]
I'm not against generated code per-se. But in the case of signals/slots, we have had a robust, type-safe solution to replace the moc implementation as pure C++ compile-time-checked constructs which is superior to the moc-generated code. This is what libsigc++ and boost::signals both do, though they don't by default do anything with introspection--but you could add that on top. Qt5.0 gets us half way there with signal connection, and that's arguably the most important part. It would be nice if it could be taken all the way, though.
With a bit of thought, it's equally possible to do properties at compile/runtime as well, including introspection. For example, using templated property proxies and lambdas for the getters/setters. Again, completely type-safe compile-time checked etc. Example: GLib::PropertyProxy<> in GLibmm; though it's layered on top of the GObject property mechanism, it could be based on something else.
For me, the value added here is the compile-time checking, robustness, simplicity, and removal of the need for an additional code-generation step in the build. You now can't get any runtime signature mismatch failures unlike with moc. Also, when Qt is just one of many libraries being used, qmake is often not an option, particularly when Qt is just for an optional UI component in a larger project. Just like bjam isn't an option when using Boost, etc (mainly because it's incomprehensible!). And writing all the extra make rules to run moc is time-consuming and fragile when you have to do it by hand, so removing it when possible can be useful.
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). And the non-standard containers can also be an issue; it would be preferable to use the C++ standard equivalents whenever possible (I know this has improved, but as someone who codes using plain Standard C++ with TR1/boost/C++11, using the standard forms by default is highly desirable). GTKmm/GLibmm manage to use standard C++ to a much greater extent, though Qt is certainly getting better, and I'm increasingly using Qt for newer projects as a result.
Regards,
Qt 5.0 released Posted Dec 20, 2012 14:36 UTC (Thu) by krake (subscriber, #55996) [Link]
"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.
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,
|
|||||||||||||