This class sets up the queue. The getReceiver/getSender methods provide two interfaces (since the sender should not be able to receive it's own messages).
For the Receiver/Sender class to access the queue I use a reference to the creating MessagePipe.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
class Receiver
{
public:
~Receiver();
bool isEmpty();
bool hasMessages();
private:
Receiver(MessagePipe& messagePipe); // <== this line
Receiver(const Receiver& other);
Receiver& operator =(const Receiver& other);
MessagePipe& messagePipe_;
friendclass MessagePipe;
};
If I know want to initalize the Receiver member of MessagePipe with a reference to the MessagePipe I receive an error stating that I use *this before the object is completely constructed:
What's with all the private/friend business? That's moving from the realm of bondage and discipline into sado-masochism. Constraining the message pipe to not permit the sender and receiver to be the same is silly. There are plenty of legitimate use cases for that.
Another thing: friendship is not inheritable so these are not "interfaces" at all.
Look at the Python Queue implementation for a good way to do message pipes.
I kicked the friend part and also the separate interfaces for sender/receiver.
I don't need a very sophisticated solution and since my version does now exactly what I want, I'll stick with it.
If the requirements should change, for example multiple senders/receivers ..., I'll switch to something like ACE.