Design question: managing limited resources

[Torsten Wiebesiek]

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

 

[Victor Bazarov]

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

 

[=?ISO-8859-1?Q?Ney_Andr=E9_de_Mello_Zunino?=]

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,

 

[Victor Bazarov]

[...] The last bit of reason left in my mind led [...]

LOL