Plugins in the class

  • Thread starter Roman Werpachowski
  • Start date
R

Roman Werpachowski

I'm trying to do something like that: define class A, which contains a
handle to the object O of class B and calls this object's member
functions. I'd like the object O to be sort of a "plugin", so that
instead of class B a class inherited from it can be substituted, that
the object O can be swapped for a different one during the lifetime of
the object of class A. So far, I've implemented it like that:

class A {
private:
B * ptrB_;
}

and added the usual set of get/set routines (they return/accept a const
B& reference), Bptr_ is set to NULL in the constructor of A. I am not
satisfied with this solution, for obvious reasons. But I can't come
with anything better which would allow so much flexibility. Any
suggestions?
 
H

Howard

Roman Werpachowski said:
I'm trying to do something like that: define class A, which contains a
handle to the object O of class B and calls this object's member
functions. I'd like the object O to be sort of a "plugin", so that
instead of class B a class inherited from it can be substituted, that
the object O can be swapped for a different one during the lifetime of
the object of class A. So far, I've implemented it like that:

class A {
private:
B * ptrB_;
}

and added the usual set of get/set routines (they return/accept a const
B& reference), Bptr_ is set to NULL in the constructor of A. I am not
satisfied with this solution, for obvious reasons. But I can't come
with anything better which would allow so much flexibility. Any
suggestions?

That looks like a pretty standard way to handle it to me. Just be sure that
B has a virtual destructor. (By the way, private is default for class
members, so you don't really need to specify it here - unless it's preceded
by protected or public specifiers of course.)

-Howard
 
R

Roman Werpachowski

I was not satisfied by the solution because someone might supply A with
a reference to local variable, which would be destructed somewhere
later and leave A with a "dangling pointer". Or am I missing something?

I like to leave such specifiers like private: for clarity. So that I
don't have to remember what is default.
 
S

Shezan Baig

Roman said:
I was not satisfied by the solution because someone might supply A with
a reference to local variable, which would be destructed somewhere
later and leave A with a "dangling pointer". Or am I missing something?


Passing automatic (local) objects to be held by non-local objects is
not a good idea. For your situation, there are 2 options that I can
think of:

- make a copy of B (if it is not expensive)
- take a shared_ptr to B (see boost::shared_ptr, for example), which
means users need to allocate the object (using 'new' or some
allocator), i.e. it should not be automatic.

Hope this helps,
-shez-
 
R

Roman Werpachowski

First is not expensive, but unwanted: I want to exploit polymorphism,
i.e. be able to subsitute

class C: public B;

for B.

I've switched to shared_ptr.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,774
Messages
2,569,596
Members
45,143
Latest member
SterlingLa
Top