Results 1 to 14 of 14

Thread: Sanitizing Qt signals

  1. #1
    Join Date
    Nov 2010
    Posts
    97
    Thanks
    6
    Thanked 11 Times in 11 Posts
    Qt products
    Qt4
    Platforms
    Windows

    Default Sanitizing Qt signals

    A while back I asked here about auto-generating Q_OBJECT classes so that I could translate Qt signals into boost signals. It more or less resulted in a flame war filled with nonsense and bad advice but one link posted in the lot ended up providing me with the linchpin that would allow me to solve the problem. I'm not done yet, but I do believe the problem solved...needing only to be implemented. I've started a blog article series that will start from the beginning and show how to implement it.

    One cool thing about this article is that it will go over the use of a lot of more modern C++ techniques involving template metaprogramming. The goal is to wrap Qt signals into an easy and quick to use function that brings type safety and static typing back into the show in addition to the ability to connect ANY function lookalike to any Qt signal.

    Here is the first entry: http://crazyeddiecpp.blogspot.com/20...qt-step-1.html
    This rude guy who doesn't want you to answer his questions.

    Note: An "expert" here is just someone that's posted a lot.

    "The fact of where you do the encapsulation is meaningless." - Qt Certified Developer and forum moderator

  2. #2
    Join Date
    Dec 2010
    Location
    US, Washington State
    Posts
    54
    Thanks
    3
    Thanked 7 Times in 7 Posts
    Qt products
    Qt4
    Platforms
    MacOS X Unix/X11 Windows

    Default Re: Sanitizing Qt signals

    Quote Originally Posted by nroberts View Post
    Overall I like the concept and will be interested in the future articles. Item 1 seems to be a personal choice, and like you I prefer strongly typed languages. That said, I'd like to see Qt's signals/slots implementation go the other direction (not strongly typed) and have capabilities like Objective-C Categories.
    Last edited by pkohut; 5th January 2011 at 03:20.

  3. The following user says thank you to pkohut for this useful post:

    nroberts (6th January 2011)

  4. #3
    Join Date
    Nov 2010
    Posts
    97
    Thanks
    6
    Thanked 11 Times in 11 Posts
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Sanitizing Qt signals

    Quote Originally Posted by pkohut View Post
    Overall I like the concept and will be interested in the future articles. Item 1 seems to be a personal choice, and like you I prefer strongly typed languages. That said, I'd like to see Qt's signals/slots implementation go the other direction (not strongly typed) and have capabilities like Objective-C Categories.
    IMHO, if you want the features of Objective-C then you should use it. At the time I was using it you couldn't use C++ libraries without wrapping them but maybe Apple's shared that bit with gcc by now? The NextStep API was pretty darn sweet though. The only thing I didn't like about it was the GNUStep implementation using its own sort of filesystem standard instead of being like other *nix apps.

    One of the main "ideals" in C++ is that you don't pay for anything you don't use. The abilities of Qt to connect to objects and send them messages they may or may not respond to isn't something I'm going to use, but I have to pay for it. I think it would have been better to provide an add-on reflection support library. In fact, I have built one that I've been using for a long time that does both runtime and compile time reflection. As a separate component it could be used/not-used as needed. Qt'll never do that though, it is what it is and you either take it or leave it.

    Yes, #1 is a personal choice. The way I see it though, if you don't like strong typing there are many other choices besides C++ to work with. One common approach these days is to write your low layers that need to be fast and safe in C++, and write your upper layers in Python. I don't see the point of forcing soft typing on a strongly typed language. Of course, when Qt was first written there were not as many options for people as there are now.

    At this point, the costs don't bother me because I'm not doing any UI stuff that's got to be fast (minus the drawing, but that's outside the sig/slot mech). I am regularly bothered by the lack of compile time checking though and the inability to connect generic functors to signals. Those two things can be fixed with a wrapper.

    Anyway, step 2 is up: http://crazyeddiecpp.blogspot.com/20...qt-step-2.html

    This one does the metaprogramming to rebuild the parameters and call the forwarding function.
    This rude guy who doesn't want you to answer his questions.

    Note: An "expert" here is just someone that's posted a lot.

    "The fact of where you do the encapsulation is meaningless." - Qt Certified Developer and forum moderator

  5. #4
    Join Date
    Jan 2006
    Location
    Belgium
    Posts
    1,938
    Thanked 268 Times in 268 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows
    Wiki edits
    20

    Default Re: Sanitizing Qt signals

    My first answer to your original post is exactly what you're doing now and you call it poor advice.

    I don't get you.

  6. #5
    Join Date
    Sep 2009
    Location
    UK
    Posts
    2,447
    Thanks
    6
    Thanked 348 Times in 333 Posts
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Sanitizing Qt signals

    You make some excellent reasonings in your article in which I am very interested. It would be awesome to be able to connect signals to standard function pointers rather than defined slots so I can put them wherever, without having to worry about defining them in header files with Q_SLOT or suchlike and ensuring I run 'moc' on the file. I always thought it was strange having both the signal and slot name and parameters in ascii text strings (which is basically what SLOT and SIGNAL macros do, for anyone getting confused) and doing so does give away information on how your application is structured and works (which sometimes you may not wish to give someone).

    I don't see how you can compare the signal signature to the slot signature (type checking) in the compile stage yet however.

    Therefore, I wish you good luck in your quest

    [BTW, I wouldn't consider this topic 'Newbie' material]

  7. #6
    Join Date
    Nov 2010
    Posts
    97
    Thanks
    6
    Thanked 11 Times in 11 Posts
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Sanitizing Qt signals

    [moderated for offensive content] I very much doubt I'll be able to continue providing notice when I've completed this topic. Those interested will just have to go see for themselves, or add yourself as a watcher. Hopefully the thread is allowed to remain so future people looking for this kind of thing can find it, but I have my doubts it'll remain intact.


    by wysota: I reedited the post to leave the part containing some merithorical content. This is a special exception as the post is in general in violation of the site rules.
    Last edited by wysota; 5th January 2011 at 22:32.
    This rude guy who doesn't want you to answer his questions.

    Note: An "expert" here is just someone that's posted a lot.

    "The fact of where you do the encapsulation is meaningless." - Qt Certified Developer and forum moderator

  8. #7
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: Sanitizing Qt signals

    Quote Originally Posted by squidge View Post
    You make some excellent reasonings in your article in which I am very interested. It would be awesome to be able to connect signals to standard function pointers rather than defined slots so I can put them wherever, without having to worry about defining them in header files with Q_SLOT or suchlike and ensuring I run 'moc' on the file. I always thought it was strange having both the signal and slot name and parameters in ascii text strings (which is basically what SLOT and SIGNAL macros do, for anyone getting confused) and doing so does give away information on how your application is structured and works (which sometimes you may not wish to give someone).
    Saying this you end up closer to the concept of callbacks which is exactly what Qt signal/slot mechanism wants to avoid. I too like the idea of using lambdas as slots although this is hardly object oriented and lambdas are not part of the C++ standard yet anyway.

    I don't see how you can compare the signal signature to the slot signature (type checking) in the compile stage yet however.
    In a general case you can't simply because some signals and some slots do not exist at a time of compilation, for example when connecting DBUS or COM (ActiveX) components.

    Commenting on nroberts' idea that signals and slots should be an addon to Qt (if I understood correctly) this wouldn't make much sense as signals and slots are the core of Qt and are used practically everywhere by Qt itself. There has been a discussion whether statically connected signals/slots would be better (sorry, no single link to give for reading) and the conclusion is that it is true that static connections (and invokations) are faster (about twice as fast as Qt's signals) but provided that you want to do anything practical in the slot, the "overhead" will be neglectible compared to the contents of the slot. Statically compiled signals also reduce functionality of signals and slots - you can then forget about dynamic introspection (for example across library boundaries).

    And concluding - if you want static signal/slot mechanism, there is one provided by boost. Qt doesn't prevent you from using boost signals in any way. On the other hand dynamic signals (such as the ones in Qt) are much much more flexible, imagine building (on the fly) a meta-object for a remote webservice based on introspected description it provides (like wsdl or something similar) and connecting that directly to signals and slots in your application. It's something that static signals will never be able to do.
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


  9. #8
    Join Date
    Nov 2010
    Posts
    97
    Thanks
    6
    Thanked 11 Times in 11 Posts
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Sanitizing Qt signals

    Quote Originally Posted by wysota View Post
    Saying this you end up closer to the concept of callbacks which is exactly what Qt signal/slot mechanism wants to avoid.
    That may be Qt's motivation but the comparison simply isn't valid. If we wanted to compare static signal/slot systems to callbacks we could as validly compare Qt's.

    I too like the idea of using lambdas as slots although this is hardly object oriented and lambdas are not part of the C++ standard yet anyway.
    OO isn't the only paradigm in C++. Qt also can't connect to members of non Qt classes.

    In a general case you can't simply because some signals and some slots do not exist at a time of compilation, for example when connecting DBUS or COM (ActiveX) components.
    Those are not general cases, they're specific ones. In general it's actually quite simple.

    Commenting on nroberts' idea that signals and slots should be an addon to Qt (if I understood correctly) this wouldn't make much sense as signals and slots are the core of Qt and are used practically everywhere by Qt itself. There has been a discussion whether statically connected signals/slots would be better (sorry, no single link to give for reading) and the conclusion is that it is true that static connections (and invokations) are faster (about twice as fast as Qt's signals) but provided that you want to do anything practical in the slot, the "overhead" will be neglectible compared to the contents of the slot. Statically compiled signals also reduce functionality of signals and slots - you can then forget about dynamic introspection (for example across library boundaries).
    Yep, the only comparison they make is performance and then show that it isn't a particularly interesting criteria. They're right, it isn't. If I was worried about performance I'd be rewriting it instead of wrapping it.

    And concluding - if you want static signal/slot mechanism, there is one provided by boost. Qt doesn't prevent you from using boost signals in any way.
    Which is kind of interesting that you say that because solving the fact that Qt CAN'T connect to a boost::signal directly is exactly the issue I'm solving.

    On the other hand dynamic signals (such as the ones in Qt) are much much more flexible, imagine building (on the fly) a meta-object for a remote webservice based on introspected description it provides (like wsdl or something similar) and connecting that directly to signals and slots in your application. It's something that static signals will never be able to do.
    And I'm sure it's nice for anyone who actually needs it. For those who don't, which I bet is a vast majority, it's just extra problems.

    Of course, this post will probably be deleted and called "offensive".
    This rude guy who doesn't want you to answer his questions.

    Note: An "expert" here is just someone that's posted a lot.

    "The fact of where you do the encapsulation is meaningless." - Qt Certified Developer and forum moderator

  10. #9
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: Sanitizing Qt signals

    Quote Originally Posted by nroberts View Post
    That may be Qt's motivation but the comparison simply isn't valid. If we wanted to compare static signal/slot systems to callbacks we could as validly compare Qt's.
    Hmm... maybe I wasn't clear enough. What I meant was being able to connect a signal to any function reduces the control over the whole mechanism which is one of the down sides of callbacks. This goes further if we have a connection to an object that gets deleted. What Qt says is "ok, we limit the possibility of using our mechanism to this and this case but we guarantee you won't hurt yourself".

    OO isn't the only paradigm in C++.
    True. Connecting signals to lambdas doesn't support any other C++ paradigm though.
    Qt also can't connect to members of non Qt classes.
    True again. And static signals can't convert from strings to integers on the fly (Qt signals can't as well although it's no problem teaching them to do that because of their dynamic nature) as they can't brew coffee and do many other things. The sole fact doesn't make them "bad" or even "incomplete". It's just a design decision which has its advantages and disadvantages.

    Those are not general cases, they're specific ones. In general it's actually quite simple.
    According to laws of logic, iIf there is at least one case that is not supported by a general hypothesis, the whole hypothesis is not true (it may be true in some specific situation but not in a general one). In other words how do you intend to teach the compiler to distinguish between the two cases just by looking at the source code?

    Yep, the only comparison they make is performance and then show that it isn't a particularly interesting criteria. They're right, it isn't. If I was worried about performance I'd be rewriting it instead of wrapping it.
    From what I understand you wish to extend the concept while at the same time limiting it in some other place. That's ok but it's hard to call it really an "extension" and it is in no way "superior" to the original.

    Which is kind of interesting that you say that because solving the fact that Qt CAN'T connect to a boost::signal directly is exactly the issue I'm solving.
    I didn't say you could connect Qt signal to a boost signal (the same way as you can't connect a boost signal to a Qt signal). I said nothing prevents you from using boost signals (for your own things) in Qt applications. I can imagine triggering a Qt signal or a Qt slot from a boost signal should be doable when providing a simple wrapper over the connection. You still need an object somewhere though (not necessarily a QObject).

    And I'm sure it's nice for anyone who actually needs it. For those who don't, which I bet is a vast majority, it's just extra problems.
    I'm sorry to inform you that if you use Qt for something more than just QStrings there is a very good chance you are using some of the functionality you would like to discard (or "work around"). And even if not you personally than at least the vast majority of beginners with Qt. Please don't assume everybody uses Qt the same way you do. It seems you have a vast knowledge about C++ but it also seems your knowledge of Qt is not that deep so don't state things you can't be sure of.

    Of course, this post will probably be deleted and called "offensive".
    No but this single sentence might be. You're pushing the limits and doing it on purpose. Please don't test our patience.
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


  11. #10
    Join Date
    Sep 2009
    Location
    UK
    Posts
    2,447
    Thanks
    6
    Thanked 348 Times in 333 Posts
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Sanitizing Qt signals

    Ok, I've finished reading the articles.

    Thinking about it, maybe the best solution is a mix of boost signals and Qt signals, but I'm not sure whether or not this will simply make code more confusing and less maintainable. I'm thinking when you come back to code that hasn't been touched for 6 - 12 months. I don't want to get confused despite the advantages that both systems have.

    Also, although your articles contain useful content, I think your bashing of this site and it's members is unnecessary, unprofessional, and not needed in an article when the main focus is about trying to get Qt Signals and Boost Signals to play nice together. People want to read content, not your personal opinion on whether you think a site is any good or not. You also seem to put some comments (such as the #ifdef blocks) out of context. They made perfect sense in the original topic and I believe they were a suitable answer to the asked question at that time.

    The amusing thing is that you say we give out "lots of really poor advice", but still post a question just this Monday, 3rd January, asking for help! If the above really was true, why would you post it here?

  12. #11
    Join Date
    Dec 2010
    Location
    US, Washington State
    Posts
    54
    Thanks
    3
    Thanked 7 Times in 7 Posts
    Qt products
    Qt4
    Platforms
    MacOS X Unix/X11 Windows

    Default Re: Sanitizing Qt signals

    Found these while looking for something unrelated -

    Combining the Advantages of Qt Signal/Slots and C# Delegates/Events
    http://www.kdedevelopers.org/node/305

    Slot classes, which are templates
    http://www.allegro.cc/forums/thread/595124

    sigslot - C++ Signal/Slot Library
    http://sigslot.sourceforge.net/

  13. The following user says thank you to pkohut for this useful post:

    nroberts (6th January 2011)

  14. #12
    Join Date
    Nov 2010
    Posts
    97
    Thanks
    6
    Thanked 11 Times in 11 Posts
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Sanitizing Qt signals

    Quote Originally Posted by pkohut View Post
    Found these while looking for something unrelated -

    Combining the Advantages of Qt Signal/Slots and C# Delegates/Events
    http://www.kdedevelopers.org/node/305
    This just looks like some sort of proposal.

    Slot classes, which are templates
    http://www.allegro.cc/forums/thread/595124
    This is a very interesting link! I'll have to look at it a bit to see what it's doing. I'm very surprised and skeptical that the connect() line works. It might be for an older version of Qt.

    sigslot - C++ Signal/Slot Library
    http://sigslot.sourceforge.net/
    Yep, I think this was the first C++ only sig/slot mechanism. GTKmm used it but now has its own (dunno why). Eventually something similar ended up in boost. Now there's the signals2 library in boost that is thread safe.

    If you haven't started using boost yet, you should.

    Thanks for the links.
    Last edited by wysota; 6th January 2011 at 12:07. Reason: wrong bbcode tag usage
    This rude guy who doesn't want you to answer his questions.

    Note: An "expert" here is just someone that's posted a lot.

    "The fact of where you do the encapsulation is meaningless." - Qt Certified Developer and forum moderator

  15. #13
    Join Date
    Nov 2010
    Posts
    97
    Thanks
    6
    Thanked 11 Times in 11 Posts
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Sanitizing Qt signals

    * - bugs need hashing out...
    Last edited by nroberts; 6th January 2011 at 23:15.
    This rude guy who doesn't want you to answer his questions.

    Note: An "expert" here is just someone that's posted a lot.

    "The fact of where you do the encapsulation is meaningless." - Qt Certified Developer and forum moderator

  16. #14
    Join Date
    Nov 2010
    Posts
    97
    Thanks
    6
    Thanked 11 Times in 11 Posts
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Sanitizing Qt signals

    Part 3 is back up. Had to peek behind protected access in order to provide type checking. Was looking for a better way. I may have found one that will end up being better for when I solve for non-void returns.

    This version uses C++0x stuff. The next part will be even more so.
    This rude guy who doesn't want you to answer his questions.

    Note: An "expert" here is just someone that's posted a lot.

    "The fact of where you do the encapsulation is meaningless." - Qt Certified Developer and forum moderator

Similar Threads

  1. Replies: 1
    Last Post: 24th October 2010, 12:09
  2. conflict between boost signals and Qt signals
    By high_flyer in forum Qt Programming
    Replies: 2
    Last Post: 26th June 2008, 10:46
  3. QThread and signals (linux/UNIX signals not Qt Signals)
    By Micawber in forum Qt Programming
    Replies: 1
    Last Post: 28th November 2007, 23:18
  4. I need help for signals
    By avis_phoenix in forum Qt Programming
    Replies: 1
    Last Post: 10th February 2007, 17:43
  5. Where are signals?
    By PanzerMaus in forum Newbie
    Replies: 1
    Last Post: 13th July 2006, 00:05

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.