This is totally breaking the whole concept of signals and slots. If you have to communicate something to a specific object, simply invoke a method on it.

peppe wrote:

This is totally breaking the whole concept of signals and slots. If you have to communicate something to a specific object, simply invoke a method on it.

Thanks for the answer.

I am thinking of a configuration class which can do following thinks:
1)Receive a configuration for a module which is stored in a map<key,map<string,string>>
key = modulename for configuration
map<string,string> = config and value pair

2) On request signal from a (specific module) for a value the config class looks if this value is set in the xml config file. If so then it send the required value to the (specific module) if not then the default value is set.

Multiple methods would cause a specialisation like

Maybe i should public inherit from the abstract config class to specialise it and put then the methods inside?

As peppe already states sending a signal only to a specific slot is in contradiction to the signal-slot concept of Qt. However, you may include in the slot parameter list a parameter allowing the receiving object to decide whether it shall process or not.

koahnig wrote:

However, you may include in the slot parameter list a parameter allowing the receiving object to decide whether it shall process or not.

Thanks for the reply

I already thought about such solution but that will cause a lot of overhead … i am still thinking of any better design idea.

The inheritance will work but i will still be dependent to include the header file from the config … i want to have a separate compilation of the dynamic libs to be possible.

When overhead is your concern than basically you can call the methods directly in the different objects as suggested by Peppe.
With signals and slots you can send different signals which are relayed to the different objects because you can decide with connect where to send. However, this is at the day’s end not much different from direct calls when the signals are processed syncronously.

Some random ideas:

• Add a QString parameter to signal in which you store the module name (key for the outer map)
• In the class that creates the modules, use a QSignalMapper to distinguish the senders

How do you send back the data?

Why is that requestConfig() signal connected to multiple receivers at all and not only to your single config provider class?