Delegation question...

[barcaroller]

What is the common way/design-pattern (if any) in C++ for delegating
function calls that are not handled by a certain class. Public
inheritance would be one way but not all classes are meant to inherit
from (e.g. STL).


Example:

class A
{
public:
foo();

private:
set<string> myset;
}

A myObj;
myObj.insert(); // compiler error of course


Is there some mechanism (direct or indirect) where a function that is
not handled by myObj gets delegated to another object (e.g. myset)?

 

[Daniel Pitts]

What is the common way/design-pattern (if any) in C++ for delegating
function calls that are not handled by a certain class. Public
inheritance would be one way but not all classes are meant to inherit
from (e.g. STL).


Example:

class A
{
public:
foo();

private:
set<string> myset;
}

A myObj;
myObj.insert(); // compiler error of course


Is there some mechanism (direct or indirect) where a function that is
not handled by myObj gets delegated to another object (e.g. myset)?

I believe you can add the following to your class:
set<string> &operator->() { return myset; }

and then you can do myObj->insert()
Although, this seems a bit troublesome.

 

[Ian Collins]

What is the common way/design-pattern (if any) in C++ for delegating
function calls that are not handled by a certain class. Public
inheritance would be one way but not all classes are meant to inherit
from (e.g. STL).


Example:

class A
{
public:
foo();

private:
set<string> myset;
}

A myObj;
myObj.insert(); // compiler error of course


Is there some mechanism (direct or indirect) where a function that is
not handled by myObj gets delegated to another object (e.g. myset)?

No, C++ does not support this form of delegation.

 

[James Kanze]

No, C++ does not support this form of delegation.

Not directly. The closest you can come, I think, is to use
private inheritance and using declarations.

Note that this type of delegation is effectively exposing part
of your internals, to some degree. Although significantly
wordier, I rather favor being explicit in forwarding, so that
the complete interface of the object isn't available. Most of
the time, at least; I also have at least one case where the
non-mutable interface of the object is exactly that of
std::vector< std::string > and I can conceive of others. Which
means that I do have to duplicate a lot (including things like
typedef's). But it's not 100% duplication either; I have
iterator typedefed to std::vector<std::string>::const_iterator,
for example.

 

[Erik Wikström]

What is the common way/design-pattern (if any) in C++ for delegating
function calls that are not handled by a certain class. Public
inheritance would be one way but not all classes are meant to inherit
from (e.g. STL).


Example:

class A
{
public:
foo();

private:
set<string> myset;
}

A myObj;
myObj.insert(); // compiler error of course


Is there some mechanism (direct or indirect) where a function that is
not handled by myObj gets delegated to another object (e.g. myset)?

Private inheritance is one way to do it:

#include <iostream>

class Foo
{
public:
void print() { std::cout << "Foo\n"; }
};

class Bar : private Foo
{
public:
using Foo:rint;
};

int main()
{
Bar b;
b.print();
}

But most often I would recommend to manually do the delegation:

#include <iostream>

class Foo
{
public:
void print() { std::cout << "Foo\n"; }
};

class Bar
{
Foo f;
public:
void print() { f.print(); }
};

int main()
{
Bar b;
b.print();
}

 

[Ian Collins]

Not directly. The closest you can come, I think, is to use
private inheritance and using declarations.

I was going to suggest that technique, but decided against it as the OP
wanted to delegate members of std::set. I wouldn't recommend deriving
from a standard container.

 

[James Kanze]

[...]

I was going to suggest that technique, but decided against it as the OP
wanted to delegate members of std::set. I wouldn't recommend deriving
from a standard container.

Not even privately? I have no problems with private inheritance
from a standard container; private inheritance is part of the
implementation.

 

[Ian Collins]

[...]

I was going to suggest that technique, but decided against it as the OP
wanted to delegate members of std::set. I wouldn't recommend deriving
from a standard container.

Not even privately? I have no problems with private inheritance
from a standard container; private inheritance is part of the
implementation.

Yes, you're right, I overlooked private inheritance.

 

[tedzhou]

On May 24, 9:47 am, Ian Collins <[email protected]> wrote:

    [...]

I was going to suggest that technique, but decided against it as the OP
wanted to delegate members of std::set.  I wouldn't recommend deriving
from a standard container.

Not even privately?  I have no problems with private inheritance
from a standard container; private inheritance is part of the
implementation.

Yes, you're right, I overlooked private inheritance.

Private inheritance is not suggested on standard container either.
Because the standard containers are not designed for inheritance at
all.
Just think about the polymorphism and virtual destruction , then
you'll
get the conclusion that inheritance from standard containors will be
dangerous.

 

[Ian Collins]

[...]
I was going to suggest that technique, but decided against it as the OP
wanted to delegate members of std::set. I wouldn't recommend deriving
from a standard container.
Not even privately? I have no problems with private inheritance
from a standard container; private inheritance is part of the
implementation.

Yes, you're right, I overlooked private inheritance.

Private inheritance is not suggested on standard container either.
Because the standard containers are not designed for inheritance at
all.
Just think about the polymorphism and virtual destruction , then
you'll
get the conclusion that inheritance from standard containors will be
dangerous.

With public inheritance maybe, but you can't point a base* to a derived
object if derived uses private inheritance. Private inheritance hides
the fact that a derived is a base. Try

class base {};
class derived : base {};

base* p = new derived;

 

[red floyd]

[...]
I was going to suggest that technique, but decided against it as the OP
wanted to delegate members of std::set. I wouldn't recommend deriving
from a standard container.
Not even privately? I have no problems with private inheritance
from a standard container; private inheritance is part of the
implementation.

Yes, you're right, I overlooked private inheritance.

Private inheritance is not suggested on standard container either.
Because the standard containers are not designed for inheritance at
all.

Not necessarily. Several of the standard adapter classes
(std:riority_queue for example) have protected members, which implies
that they were designed to be inherited from.

 

[Kai-Uwe Bux]

On May 24, 9:47 am, Ian Collins <[email protected]> wrote:

[...]
I was going to suggest that technique, but decided against it as the
OP wanted to delegate members of std::set.  I wouldn't recommend
deriving from a standard container.

Not even privately?  I have no problems with private inheritance
from a standard container; private inheritance is part of the
implementation.

Yes, you're right, I overlooked private inheritance.

Private inheritance is not suggested on standard container either.
Because the standard containers are not designed for inheritance at
all.
Just think about the polymorphism and virtual destruction , then
you'll
get the conclusion that inheritance from standard containors will be
dangerous.

That argument is bogus for two reasons:

(a) As others have pointed out, private differs from public inheritance with
regard to destruction.

(b) Even with public inheritance, the argument does not hold as it would
apply equally well to std::unary_function or std::iterator, two classes
that are meant to be publicly inherited from and that lack virtual
destructors. Inheritance in C++ is not necessarily tied to polymorphism.

[Note: that you failed to point out a valid reason as to why public
inheritance from standard containers might not be such a good move, is not
to say that there are no such reasons. However, those tend to focus on
other issues rather than the lack of a virtual destructor.]


Best

Kai-Uwe Bux

 

[James Kanze]

James Kanze wrote:
[...]
I was going to suggest that technique, but decided against it as the OP
wanted to delegate members of std::set. I wouldn't recommend deriving
from a standard container.
Not even privately? I have no problems with private inheritance
from a standard container; private inheritance is part of the
implementation.
Yes, you're right, I overlooked private inheritance.

Private inheritance is not suggested on standard container
either. Because the standard containers are not designed
for inheritance at all. Just think about the polymorphism
and virtual destruction , then you'll get the conclusion
that inheritance from standard containors will be dangerous.

With public inheritance maybe, but you can't point a base* to
a derived object if derived uses private inheritance.

You can, and in fact, one frequent use of private inheritance
involves doing just that. But you need cooperation from the
derived class to do so: if the derived class doesn't give you
the Base*, you can't get it otherwise. (The "frequent use" is
to derive privately from something like "EventHander": for
normal client code, this is an implementation detail, and they
can't consider the class to be an EventHander. But the class
itself may register itself as an EventHander with some
EventNotifier, who will address the class through an
EventHander*.)

Private inheritance hides the fact that a derived is a base.

Except in the explicit cases where it wants to behave as a base.

None of which is really a problem when deriving privately from a
standard container, since you, the author of the class, have
total control, and of course, you will not expose the
derivation.