Qt Forum

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Unsolved

    Update: Forum Guidelines & Code of Conduct

    Unsolved Guard sentinels for slots?

    General and Desktop
    3
    3
    244
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Kent-Dorfman
      Kent-Dorfman last edited by Kent-Dorfman

      Back in the Qt4 days I occasionally ran across references that recommended a guard around slots to prohibit the slot from being recursively called. Here's a quick implementation:

      MyQObject::MySlot() {
          static bool inSlot(false);    // probably better to make this a member variable
          if (!inSlot) {
              inSlot = true;
              // *** do important slot stuff ***
              // maybe emit signals that in a round-about way 
              // cause this slot to be executed again?
              inSlot = false;
          }
      }
      

      Is this still a thing? Does Qt5 have any internal checks to make this kind of blocking redundant? Being an admittedly paranoid person, I still frequently do this to protect from signal/slot loops causing a stack overflow.

      What's the best practice and caveats these days?

      JKSH JonB 2 Replies Last reply Reply Quote 0
      • JKSH
        JKSH Moderators @Kent-Dorfman last edited by

        @Kent-Dorfman said in Guard sentinels for slots?:

        Does Qt5 have any internal checks to make this kind of blocking redundant?

        I don't think so.

        The techniques you used in Qt 4 are still valid for Qt 5.

        Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

        1 Reply Last reply Reply Quote 4
        • JonB
          JonB @Kent-Dorfman last edited by

          @Kent-Dorfman
          As @JKSH says you are still responsible for writing explicit code if you want this check. Doubtless you're well aware already, but (a) you could have this in debug/development code only if you trust to skip it in production and (b) personally in some shape or form I'd implement via, say, a function-scoped local variable whose constructor sets and destructor clears the inSlot so that you don't have to worry about putting a return in the middle of your code or an exception being raised etc.

          1 Reply Last reply Reply Quote 0
          • First post
            Last post