By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,837 Members | 1,813 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,837 IT Pros & Developers. It's quick & easy.

compile time efficency / run time flexibility - best of both worlds

P: n/a
Suppose one is writing a library behavior the classes A1, A2 and A3, which
share some common behavior. Some applications will only use one of the
classes, while other applications will use all of them.

Because the classes share common behavior, the library designed has to
choose wether to introduce an abstract base class A, or not. Introducing an
ABC has the advantage of run time flexibility, but efficiency suffers
(virtual functions & inlining, ...).

To have the best of both worlds, you could try this:

class A1 // no inheritance
{
// no virtuals
f();
};

class A2
{
f();
};

class A3
{
f();
};

class A
{
virtual f();
};

template <class Ax>
class A_wrapper : public A
{
public:
A_wrapper(Ax& a) : a_(a) {}
f() { return a_.f(); }
private:
Ax a_;
}

Applications that use only one of the classes:

A2 a2;
a2.f();

Applications that need run time flexibility:

A * a = new A_wrapper<A2>(A2());

What do you think of this library design technique ?
Note that this technique could be applied to e.g. the random number facility
that was proposed to the standard.
Most applications will choose one random number generator and use it, e.g.
mersenne_twister or linear_congruential.
However, some applications will (for example) want to study the effect the
random number generator has on their simulation. For these applications,
run time flexibility is important.
Run time flexibility can be accomplished by introducing the base class
uniform_random_number_generator, and the class
uniform_random_number_generator_wrapper<T>. Note that
uniform_random_number_generator already exists, as a concept (table 5.1),
and the uniform_random_number_generator_wrapper<T> class is very simple,
just because all existing classes already are implemented according to the
uniform_random_number_generator concept. And even if a class had a slightly
different interface, the problem could be solved using an explicit
specialization of the uniform_random_number_generator_wrapper class
template.

So again, what do you think of this library design technique ?

best regards,
Ares Lagae
Jul 22 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
In article <10***************@seven.kulnet.kuleuven.ac.be>,
Ares Lagae <ar********@cs.kuleuven.ac.be> wrote:
Suppose one is writing a library behavior the classes A1, A2 and A3, which
share some common behavior. Some applications will only use one of the
classes, while other applications will use all of them.

Because the classes share common behavior, the library designed has to
choose wether to introduce an abstract base class A, or not. Introducing an
ABC has the advantage of run time flexibility, but efficiency suffers
(virtual functions & inlining, ...).

To have the best of both worlds, you could try this:

class A1 // no inheritance
{
// no virtuals
f();
};

class A2
{
f();
};

class A3
{
f();
};

class A
{
virtual f();
};

template <class Ax>
class A_wrapper : public A
{
public:
A_wrapper(Ax& a) : a_(a) {}
f() { return a_.f(); }
private:
Ax a_;
}

Applications that use only one of the classes:

A2 a2;
a2.f();

Applications that need run time flexibility:

A * a = new A_wrapper<A2>(A2());

What do you think of this library design technique ?


Unnecessary.

class A { virtual ~A() { } virtual void f() = 0; };

class A1 { void f(); };

To use only one of the classes:

A1 a1;
a1.f();

The above will pre-bind. The virtual mechanism will not be used.
Jul 22 '05 #2

P: n/a
Unnecessary.

class A { virtual ~A() { } virtual void f() = 0; };

class A1 { void f(); };

To use only one of the classes:

A1 a1;
a1.f();

The above will pre-bind. The virtual mechanism will not be used.


The why do new proposals (like the random number library) don't use abstract
base classes ? Are most C++ programmers still "afraid" of virtuals ?

best regards,
Ares Lagae

Jul 22 '05 #3

P: n/a
Ares Lagae <ar********@cs.kuleuven.ac.be> wrote:
Unnecessary.

class A { virtual ~A() { } virtual void f() = 0; };

class A1 { void f(); };

To use only one of the classes:

A1 a1;
a1.f();

The above will pre-bind. The virtual mechanism will not be used.


The why do new proposals (like the random number library) don't use abstract
base classes ? Are most C++ programmers still "afraid" of virtuals ?


Because they are out of vogue in C++ right now. Notice that very little
of the standard library use classes that contain virtual
member-functions. Off hand, I think that the only portion of the
standard that does use virtuals is the IO library, which pre-dates the
STL proposal (i.e. came into existence while classes with virtual
member-functions were more popular.)
Jul 22 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.