By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,171 Members | 1,020 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,171 IT Pros & Developers. It's quick & easy.

Design question: managing limited resources

P: n/a
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
Jul 23 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
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
Jul 23 '05 #2

P: n/a
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
Jul 23 '05 #3

P: n/a
"Ney André de Mello Zunino" <zu****@inf.ufsc.br> wrote...
[...] The last bit of reason left in my mind led [...]


LOL
Jul 23 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.