55

What happens if the same signal and slot is connected twice?

How is the mechanism handled?

iTayb
  • 12,373
  • 24
  • 81
  • 135
itapadar
  • 723
  • 2
  • 6
  • 8

3 Answers3

58

A few weeks ago, we had an intern accidentally connect a signal to a slot more than once. The idea was that under one condition, you'd have the slot connected to the signal, and under another condition you'd disconnect it. When you changed modes, you'd do the appropriate work.

Well, he forgot to to disconnect when appropriate. So every time you changed modes, you had a new connection to the slot.

The end result? 1 connection == 1 call to slot. 2 connections == 2 calls to slot. 3 connections == 3 calls to slot, etc. These calls happened "simultaneously" (I know in actuality they did not since they are on the same event thread, but what I mean was all calls were processed in succession).

As mtvec points out in one of his comments (he deserves credit, so please do not upvote me for his work), Qt::UniqueConnection will prevent this issue.

Abderrahmene Rayene Mihoub
  • 1,875
  • 3
  • 6
  • 19
San Jacinto
  • 8,774
  • 5
  • 43
  • 58
  • 72
    Note that you can use [Qt::UniqueConnection](http://doc.trolltech.com/latest/qt.html#ConnectionType-enum) to prevent this scenario. – mtvec Aug 20 '10 at 12:32
9

Usually bad things. It's perfectly acceptable to connect the slot twice or even more times but when the signal gets fired your slot will be called for each connection you made which is probably not what you want.

Note that it is not necessarily wrong to have multiple connections. There are (probably) perfectly valid uses for it. They are quite rare, I certainly can't think of any time I've used it as a feature. All the situations I can recall where there was a multiple connection turned out to be a bug rather than intended.

Troubadour
  • 13,334
  • 2
  • 38
  • 57
  • Ok, What exactly is there in the moc file? doesnt it have any capability to handle this kind of scenarios of prpgramming mistakes? – itapadar Aug 20 '10 at 11:59
  • @itapadar: I don't think they bother trying to prevent it because it might _not_ be a mistake. I wrote some code not that long ago that actually relied on that feature in some situations. – Troubadour Aug 20 '10 at 12:02
  • @itapadar: Actually on thinking back I didn't use it as a feature at all. It appeared as a bug and I had to work around it. – Troubadour Aug 20 '10 at 12:14
  • One useful example is a timer that calls multiple unrelated functions. You could write one function that calls those multiple unrelated functions, or just connect the timer signal to each of them – Shahbaz Nov 17 '15 at 23:21
8

The slot is executed multiple times (as others said already).

Some more notes:

  • In former times, the pattern for "connect exactly once" in cases where there might have been a connection before, was to first call disconnect and then connect to enforce exactly one connection.
  • Now, since 4.6, there is also the more elegant Qt::UniqueConnection, see http://doc.qt.io/qt-5/qt.html#ConnectionType-enum
Christophe Weis
  • 2,518
  • 4
  • 28
  • 32
Frank Osterfeld
  • 24,815
  • 5
  • 58
  • 70
  • 1
    I'm not so sure it's a more elegant solution. Usually the code should be symmetric and if it's not then that's a bug. I worry that `Qt::UniqueConnection` might be used to patch sloppy asymmetric code more times than it's used for any other purpose. – Troubadour Aug 20 '10 at 12:51
  • Yeah, one can argue that both "connecting once" approaches are not nice. OTOH, if you get an object handed in from somewhere else, potentially multiple times the same object, and all you must do is to listen to some signal (once), then the only other way i can think of is to keep lists of the objects you already have seen. Not nice either. And disconnect(), connect() is a bit fragile, as one has to take care to keep them in sync if something changes. So I'd prefer UniqueConnection. In practice, I see neither "connect once" approach very often so it seems to be not a big problem. – Frank Osterfeld Aug 20 '10 at 13:30