C++Talk.NET

Andrei Alexandrescu (See · Guest

Imagine a design that pursues efficiency combined with flexibility. The
core is a set of transformation functions, which I'll model as taking
and returning integers.

I defined a base class like this:

struct Base {
virtual int Transform(int) = 0;
virtual ~Base() {}
};

Then I define a number of implementation of Base. At a point, I need to
cascade two such implementations, hence:

template <class First, class Second>
struct Combo : Base {
virtual int Transform(int x) {
return second_.Transform(first_.Transform(x));
}
private:
First first_;
Second second_;
};

I count on the fact that the compiler will be smart enough to figure out
that the two calls inside Combo::Transform aren't really virtuals. It
does. I can now combine objects in the Base hierarchy in interesting
ways, without big penalties in efficiency. Cool.

I also need to create objects from a factory. That is, a parameter is
read from the command line and a Base-derived object must be created
dynamically. Then the Combo trick doesn't work anymore; I'd need a Combo
that stores two pointers and delegates calls to them. Something like:

struct DynaCombo : Base {
// ctor etc.
virtual int Transform(int x) {
return second_->Transform(first_->Transform(x));
}
private:
First * first_;
Second * second_;
};

At this point I realize that DynaCombo could really reuse Combo's design
if only it used references:

struct DynaCombo : public Combo<Base &, Base &> {
// almost nothing to do!
};

Nicey. The problem is resource disposal: DynaCombo would have to hold
dynamically-allocated pointers (they come from a factory) and therefore
its destructor must delete those pointers. So here's a hack I came up with:

template <class First, class Second>
struct Combo : Base {
// ctor used by bona fide instantiations
Combo() {}
// ctor used by DynaCombo
Combo(First f, Second s) : first_(f), second_(s) {}
virtual int Transform(int x) {
return second_.Transform(first_.Transform(x));
}
protected:
First first_;
Second second_;
};

struct DynaCombo : public Combo<Base &, Base &> {
DynaCombo(Base * f, Base * s) :
Combo<Base &, Base &>(*f, *s) {}
~DynaCombo() {
// oy!
delete &first_;
delete &second_;
}
};

I have a few doubts about the validity and elegance of this design. For
a short quantum of time, the references first_ and second_ will pass (in
front of the eyes of Combo's and Base's destructors) not as two
triumphant comedians exiting the stage in thundering applause, but
instead as two burned corpses. I'm not sure how legal that is, and even
if it is, it's a fragile design as it relies on the destructors of Combo
and Base having empty bodies.

I could have Combo's destructor detect references and delete them, but I
also want to use Combo in other circumstances, when it's not supposed to
do that. I could also define some "smart references", but I'm looking
for a simple solution. So: (1) is the code legal as it is? (2) any ideas
for a better variant that maintains the advantage of simplicity?

Thanks,

Andrei

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Howard Hinnant · Guest

In article <Iv0sKK.1upo (AT) beaver (DOT) cs.washington.edu>,
"Andrei Alexandrescu (See Website For Email)"
<SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> wrote:

Carl Barron · Guest

In article <Iv0sKK.1upo (AT) beaver (DOT) cs.washington.edu>, See Website For
Email <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> wrote:

David Abrahams · Guest

"Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> writes:

werasm · Guest

Andrei Alexandrescu (See Website For Email) wrote:

Dave Harris · Guest

SeeWebsiteForEmail (AT) moderncppdesign (DOT) com (Andrei Alexandrescu (See Website
For Email)) wrote (abridged):

Peter Dimov · Guest

Andrei Alexandrescu (See Website For Email) wrote:

olegabr · Guest

The simplest solution til now :)

#include <iostream>

struct Base {
virtual int Transform(int) = 0;
virtual ~Base() {}
};

template <class First, class Second>
struct Combo : Base {
// ctor used by bona fide instantiations
Combo() {}
// ctor used by DynaCombo
Combo(First f, Second s) : first_(f), second_(s) {}

virtual int Transform(int x) {
return second_.Transform(first_.Transform(x));
}
private:
First first_;
Second second_;
};

template <class First, class Second>
struct Combo<First*, Second*> : Base {
// ctor used by bona fide instantiations
Combo() {}
// ctor used by DynaCombo
Combo(First* f, Second* s) : first_(f), second_(s) {}
~Combo() {
delete first_;
delete second_;
}

virtual int Transform(int x) {
return second_->Transform(first_->Transform(x));
}
private:
First* first_;
Second* second_;
};

struct DynaCombo : public Combo<Base*, Base*> {
DynaCombo(Base * f, Base * s) :
Combo<Base*, Base*>(f, s) {}
};

struct Times10 : Base
{
virtual int Transform(int v){ return v*10; }
virtual ~Times10() {}
};

struct Square : Base
{
virtual int Transform(int v){ return v*v; }
virtual ~Square() {}

};

int main()
{
Base* a = new Times10();
Base* b = new Square();

DynaCombo dc( a, b );
std::cout << dc.Transform( 7 ) << std::endl;

return 0;
}

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

olegabr · Guest

The simplest way to maintain simplicity, I believe, is to use "smart
references"
I can not see another way to express
1) custom deletion (for pointers and auto objects)
2) custom invocation syntax (for pointers and auto objects)

It can be done with some kind of Deletion policy and Invocation policy
for original Combo class
but it is not simpler then just factor out these policies to "smart
reference" class
moreover, it'll lead to more clean design

Hope it helps,
Oleg Abrosimov

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

johnchx2@yahoo.com · Guest

Andrei Alexandrescu (See Website For Email) wrote:

Andrei Alexandrescu (See · Guest

Carl Barron wrote:

Przemyslaw Szymanski · Guest

Andrei Alexandrescu (See Website For Email) wrote:

Carl Barron · Guest

In article <Iv3t0p.22xH (AT) beaver (DOT) cs.washington.edu>, See Website For
Email <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> wrote:

Andrei Alexandrescu (See · Guest

Howard Hinnant wrote:

Andrei Alexandrescu (See · Guest

Peter Dimov wrote: