Slots & Signals w/ parameters passed by reference.

[Wazman]

I'm working on a (1) object that is needs to signal another (2) object that some data is ready for processing. But I need to distinguish if the (2) object needs to initialize how the data is processed for the first time. I had thought that I could pass a boolean value via pass-by-reference and then allow the slot to change it so when some more data is ready to be processed the slot wouldn't initialize it the second time around.

Example Code:

connect(this, SIGNAL(readySendData(bool &, MyData &)), 
           this, SLOT(sendData(bool &, MyData &)));
 
 
void DataProcessor::sendData(bool & intializationNeeded, MyData & data)
{
      if(intializationNeeded)
      {
         // Do Initialization Stuff
         intializationNeeded = false;
       } 
       else 
       {
          // Do Stuff
       }
}

connect(this, SIGNAL(readySendData(bool &, MyData &)), 
           this, SLOT(sendData(bool &, MyData &)));


void DataProcessor::sendData(bool & intializationNeeded, MyData & data)
{
      if(intializationNeeded)
      {
         // Do Initialization Stuff
         intializationNeeded = false;
       } 
       else 
       {
          // Do Stuff
       }
}

To copy to clipboard, switch view to plain text mode 

Hopefully this is clear but I would like to check to see if initialization is needed. Then the slot will change the parameter from true to false. So then next time the signal readySendData is generated it will enter the else code block. Is this possible with Slots and Signals or does it violate the loose coupling scheme.

[ktk]

It should work.

[wysota]

Wouldn't it be better to send a signal to the original emitter that you have initialized something and then next time it (the original emitter) would emit a signal with a boolean value set to false meaning that the data needn't be evaluated?

Sending references via signals is a really bad idea

[Wazman]

Wouldn't it be better to send a signal to the original emitter that you have initialized something and then next time it (the original emitter) would emit a signal with a boolean value set to false meaning that the data needn't be evaluated?

Sending references via signals is a really bad idea

Wysota

Can I ask why is sending references via signal is a really bad Idea?

[aamer4yu]

Signals can be connected with any slot of any class.
Say if some unintended class catches ur signal and modifies the data in a wrong manner ???
Isnt it a bad idea

[wysota]

Furthermore it's not possible to send such a signal across threads.

[ktk]

Furthermore it's not possible to send such a signal across threads.

That's true (in fact, it holds for queued connections in general),
and there also the mentioned pitfalls with multiple connection.

But still, it works for direct connections and makes the code
on the sender side much simpler. A second connection for
passing the result back forces the sender to split the calling
function, and there isn't a guarantee that other object connect
to the return slot either.

[wysota]

The design is nasty. I'm sure you could think of something better. Maybe using signals and slots is not the right way to go here?