Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Delegation question...

Reply
Thread Tools

Delegation question...

 
 
barcaroller
Guest
Posts: n/a
 
      05-23-2008
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)?
 
Reply With Quote
 
 
 
 
Daniel Pitts
Guest
Posts: n/a
 
      05-23-2008
barcaroller wrote:
> 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.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      05-23-2008
barcaroller wrote:
> 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.

--
Ian Collins.
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      05-24-2008
On 24 mai, 00:43, Ian Collins <(E-Mail Removed)> wrote:
> barcaroller wrote:
> > 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.


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.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
Erik Wikström
Guest
Posts: n/a
 
      05-24-2008
On 2008-05-23 23:58, barcaroller wrote:
> 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();
}

--
Erik Wikström
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      05-24-2008
James Kanze wrote:
> On 24 mai, 00:43, Ian Collins <(E-Mail Removed)> wrote:
>> barcaroller wrote:
>>> 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.

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

--
Ian Collins.
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      05-24-2008
On May 24, 9:47 am, Ian Collins <(E-Mail Removed)> 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.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      05-24-2008
James Kanze wrote:
> On May 24, 9:47 am, Ian Collins <(E-Mail Removed)> 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.

--
Ian Collins.
 
Reply With Quote
 
tedzhou
Guest
Posts: n/a
 
      05-26-2008
On May 24, 5:19*pm, Ian Collins <(E-Mail Removed)> wrote:
> James Kanze wrote:
> > On May 24, 9:47 am, Ian Collins <(E-Mail Removed)> 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.
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      05-26-2008
tedzhou wrote:
> On May 24, 5:19 pm, Ian Collins <(E-Mail Removed)> wrote:
>> James Kanze wrote:
>>> On May 24, 9:47 am, Ian Collins <(E-Mail Removed)> 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. Private inheritance hides
the fact that a derived is a base. Try

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

base* p = new derived;

--
Ian Collins.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
delegation question, where I want prototype style delegation Sam Roberts Ruby 4 05-07-2008 05:48 AM
Stub Zone vs. Delegation (70-291) a_bleem_user Microsoft Certification 2 04-25-2005 07:30 PM
cross - tier event delegation ruselw@gmail.com ASP .Net 2 02-02-2005 04:00 AM
Problem with delegation from ASP.NET to SQL Kelly D. Jones ASP .Net 0 09-17-2003 07:42 PM
Problem with impersonation and delegation Kelly D. Jones ASP .Net 1 09-12-2003 04:43 PM



Advertisments