Design question: managing limited resources

Discussion in 'C++' started by Torsten Wiebesiek, Feb 18, 2005.

  1. Hi,

    I am currently working on a computer vision system. At the moment I'm adding
    support for firewire cameras. Since there is only one firewire system on a
    computer, I have writen a firewire manager class as Singleton.

    User access to firewire camera objects should only be accessable via
    refereces obtained from this manager class. I want to avoid the creation of
    more than one camera object accessing the same physical camera.

    One solution might be making the constuctor (and the copy constructor) of
    the camera class private and declaring the manager class a 'friend' to the
    camera class:

    class FwCamera {
    private:
    FwCamera ();
    public:
    ...
    friend class FwManager;
    }

    class FwManager {
    public:
    FwCamera& getCamera(int number_of_camera);
    ...
    }

    Now only FwManger can control the construction and destruction of FwCamera
    objects. The user can only get access to camera objects via the manager
    class.

    What I don't like is the keyword 'friend'. Is there a better way, to achieve
    my my goals?

    Thanks in advance,

    Torsten
    Torsten Wiebesiek, Feb 18, 2005
    #1
    1. Advertising

  2. Torsten Wiebesiek wrote:
    > I am currently working on a computer vision system. At the moment I'm adding
    > support for firewire cameras. Since there is only one firewire system on a
    > computer, I have writen a firewire manager class as Singleton.
    >
    > User access to firewire camera objects should only be accessable via
    > refereces obtained from this manager class. I want to avoid the creation of
    > more than one camera object accessing the same physical camera.
    >
    > One solution might be making the constuctor (and the copy constructor) of
    > the camera class private and declaring the manager class a 'friend' to the
    > camera class:
    >
    > class FwCamera {
    > private:
    > FwCamera ();
    > public:
    > ...
    > friend class FwManager;
    > }
    >
    > class FwManager {
    > public:
    > FwCamera& getCamera(int number_of_camera);
    > ...
    > }
    >
    > Now only FwManger can control the construction and destruction of FwCamera
    > objects. The user can only get access to camera objects via the manager
    > class.
    >
    > What I don't like is the keyword 'friend'. Is there a better way, to achieve
    > my my goals?


    Have either a nested class in FwCamera, which will keep the record of the
    cameras it creates. Essentially you just put your FwManager inside the
    FwCamera class and let them talk to each other.

    If your compiler is such that will still require to declare FwManager
    a friend (shouldn't really be necessary since it's a member and a member
    should be allowed to access all members of its class), then you just
    dissolve the managing functionality in the FwCamera class itself -- have
    a "factory method" which will account the cameras created and return them
    (or references or pointers to them).

    class FwCamera {
    FwCamera(); // private c-tor
    public:
    class Manager {
    static FwCamera* getCamera();
    };
    };

    ...
    // the user writes
    FwCamera* pCamera = FwCamera::Manager::getCamera();

    Now, when you create other cameras, let them have a similar 'Manager'
    class nested in them and the handling is going to be very similar.

    In case when you need to dissolve the managing functionality, do something
    like:

    class FwCamera {
    FwCamera(); // private c-tor
    public:
    static FwCamera* getCamera(); // will create a new one or return
    // one of the pre-created ones
    };

    What you seem to be using is an extended "Singleton" pattern and as I
    already mentioned a "Factory" or a "Factory Method" pattern. Read about
    them in your favourite patterns source (book, NG, web).

    V
    Victor Bazarov, Feb 18, 2005
    #2
    1. Advertising

  3. Victor Bazarov wrote:

    > If your compiler is such that will still require to declare FwManager
    > a friend (shouldn't really be necessary since it's a member and a member
    > should be allowed to access all members of its class), [...]


    I was shocked at first when I read that, for as long as I could
    remember, every source I had ever consulted would state otherwise,
    namely that nested class members were given no special privileges in
    acessing the members of its nesting class.

    I wrote a little test program and was even more shocked to see it get
    through 2 different compilers (GCC 3.3.3 and MSVC 13.10.3077), as I was
    sure I had had similar code fail compilation in the past. I felt
    strongly tempted to post a message to this newsgroup in order to find
    out what was going on. The last bit of reason left in my mind led me to
    try Google Groups first and there was where I found a mention of "Defect
    report 45" which addresses that very issue. Phew! What a relief...

    Regards,

    --
    Ney André de Mello Zunino
    =?ISO-8859-1?Q?Ney_Andr=E9_de_Mello_Zunino?=, Feb 19, 2005
    #3
  4. "Ney André de Mello Zunino" <> wrote...
    > [...] The last bit of reason left in my mind led [...]


    LOL
    Victor Bazarov, Feb 19, 2005
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. SpamProof
    Replies:
    3
    Views:
    636
    SpamProof
    Dec 1, 2003
  2. Rhino
    Replies:
    4
    Views:
    724
    Rhino
    Mar 24, 2005
  3. Paul J. Lucas
    Replies:
    14
    Views:
    738
    Mike Schilling
    Aug 24, 2005
  4. Russell E. Owen
    Replies:
    0
    Views:
    690
    Russell E. Owen
    Sep 8, 2006
  5. Replies:
    0
    Views:
    118
Loading...

Share This Page