Is emitting a disconnected signal bad?

I defined a signal in myapp and emit it in very different pla开发者_如何学Goces within code, but I need it just when my MY_DEFINED_FLAG is defined, my question is:

Do I should change every:

emit mySignal();

to

#ifdef MY_DEFINED_FLAG
emit mySignal();
#endif

?

and if the answer is "yes" then, is there a better idea?

---

The class that emits the signal shouldn't care if anybody listens or not. Users of the class connect to the signals if they need to, or not. Maybe they just need to connect to some of them. There is no harm to a signal nobody is connected to, the call itself is cheap. It's like with every other part of the API: signals are part of the interface design, a service provided by the class to the users, who might use this part of the API, or not, which is their own business.

---

Emitting a signal which is not connected to any receiver/slot is completely harmless (except the rare case when you might be excessively worried about performance, but emitting a signal is really rather cheap).

Disabling some signals at compile time (using a preprocessing directive, as you suggested), is probably only warranted if you have some signals for debugging purposes in your code, which you don't want to emit in your final release.

---

No, emitting a signal that has been disconnected is not bad, it's completely expected. Qt itself does this all the time.

In that case, I'd only put the connection in the #ifdef or, ideally, just inside something like this:

if (MY_DEFINED_FLAG)
    connect(this, SIGNAL(mySignal()), this, SLOT(mySlot());