questionsolved  Interface design

onur (49)   Link to this post
Hello,
I want to create a MessageQueue class.

My current interface looks like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
  class MessagePipe
  {
  public:
    MessagePipe();
    ~MessagePipe();
    
    Sender& getSender();
    Receiver& getReceiver();


  private:
    bool isEmpty();
    bool hasCapacityLeft();
    void send(Message& message);
    Message receive();

    //...

    Sender senderInterface_;
    Receiver receiverInterface_;

    friend class Receiver;
    friend class Sender;
  };


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_;

    friend class 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:

1
2
3
4
5
6
7
 
  MessagePipe::MessagePipe()
    : 
    //...
    , senderInterface_( *this )
    , receiverInterface_ (*this )
  {
  }


I think this should be no problem since the members cannot be accessed before the construction and only store the reference.

I could create the sender/receiver interfaces dynamically after initialization step but I don't think that would be a good solution.

Anybody got a good idea?
PanGalactic (778)   Link to this post
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.
writetonsharma (832)   Link to this post
See ACE_Message_queue implementation for some good ideas.
Adaptive Communication Environment, a C++ library.
PanGalactic (778)   Link to this post
writetonsharma is right -- don't re-invent the wheel. Most people have already written most of the infrastructure components for you.
onur (49)   Link to this post
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.

Tanks for the advice!

This topic is archived - New replies not allowed.