Plugins in the class

[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?

[Howard]

"Roman Werpachowski" <ro****************@gmail.com> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.com...

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

[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.

[Shezan Baig]

Roman Werpachowski wrote:

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-

[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.