From: srp113 on
Hi Guys,
I see that inheritance allows the paradigm of "programming to
interface" with ease.A client can store a pointer to abstract base
class and invoke operaitons on it without caring about the concrete
derived class that pointer points to. Inheritance seems to allow
programming to interface naturally because of dynamic binding.
While templates clearly allow reuse: put common code into
unspecialized template class and each specialization can have its own
specialized code that could call the common code from unspecialized
class, they dont seem to "allow programming to interface paradigm",
because they are bound at compile time, I cannot have an abstract base
class (interface) initialized with different versions of specialized
templates. This seems to be one reason why inheritance would be
preferred over templates.
Let me know your thoughts.
Thanks

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

From: Goran on
On Nov 17, 3:12 am, srp113 <sunilsreenivas2...(a)yahoo.com> wrote:
> While templates clearly allow reuse: put common code into
> unspecialized template class and each specialization can have its own
> specialized code that could call the common code from unspecialized
> class, they dont seem to "allow programming to interface paradigm",
> because they are bound at compile time, I cannot have an abstract base
> class (interface) initialized with different versions of specialized
> templates.

Well that's because, with templates, you don't need one. With
templates you get e.g.:

template<class T>
retval function(T& param1, whatever_type other_params)
{
...
param.interface_member1(other_params);
...
param.interface_member2(other_params);
...
}

class c1
{
public:
void interface_member1(whatever_type other_params) { workworkwork; }
void interface_member2(whatever_type other_params) { workworkwork; }
};

class c2_completely_unrelated_to_c1
// !!!But having the "interface" required by function<>
{
public:
void interface_member1(whatever_type other_params) { workworkwork; }
void interface_member2(whatever_type other_params) { workworkwork; }
};

You can create a common base class for c1 and c2, but that does not
matter. In fact, since this is about "compile-time polymorphism", it's
undesirable, and worse for performance-wise.

In a way, this use is a classic "speed versus space" comprimise: with
"classic" runtime polymorphism you get space at the expense of speed
(speed loss is virtual call). With template-based compile-time
polymorphism, you get speed (no virtual calls) at the expense of size
(compile generates multiple versions of function<>). Of course, things
are never black-and-white, because code size has a speed impact (e.g.
swapping in/out portions due to a a big executable code base).

Goran.


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

From: Gerhard Menzl on
srp113 wrote:

> I see that inheritance allows the paradigm of "programming to
> interface" with ease.A client can store a pointer to abstract base
> class and invoke operaitons on it without caring about the concrete
> derived class that pointer points to. Inheritance seems to allow
> programming to interface naturally because of dynamic binding.
> While templates clearly allow reuse: put common code into
> unspecialized template class and each specialization can have its own
> specialized code that could call the common code from unspecialized
> class, they dont seem to "allow programming to interface paradigm",
> because they are bound at compile time, I cannot have an abstract base
> class (interface) initialized with different versions of specialized
> templates. This seems to be one reason why inheritance would be
> preferred over templates.

Short answer:

Inheritance is a way to do runtime polymorphism. Templates are a
mechanism to implement compile-time polymorphism. You use whatever is
appropriate. This is a matter of preference only in a very general
sense: catching errors at compile-time is generally cheaper than
catching errors at runtime. Apart from that, there is no easy rule.

Note that the basic idea behind a class template is not to specialize it
for every single subtype, although the language would permit it. The
idea is to use otherwise unrelated types that conform to the same
implicit interface (i.e that support the same operations but are not
derived from a common base class) in a uniform way.

The long answer would fill a book or two.

--
Gerhard Menzl

Non-spammers may respond to my email address, which is composed of my
full name, separated by a dot, followed by at, followed by "fwz",
followed by a dot, followed by "aero".



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

From: Taras Shevchuk on
srp113 написав(ла):
> This seems to be one reason why inheritance would be
> preferred over templates.

I use inheritance for reuse code from object which have some logic in
common. For example, for reuse code from base classes (base dialog class
in GUI application have common logic for derived classes, derive domain
class from base class e.g. derive RegionMeasure class from Measure class
because RegionMeasure include Measure and add some specific information
for region).
Also inheritance is good solution for move implementation details from
..h to .cpp class (we can see that in pimpl idiom).

Template programming I generally use with STL and BOOST libraries which
are based on templates. In general templates allow to create classes
with type arguments and specify them from user code. Also it allow us to
perform some calculations, checks or choose some part of code on compile
time.

In my opinion template programming is good choice for libraries
development. It allow to make more flexible interface.
In other hand inheritance is preferred to use in overall application design.


Taras Shevchuk


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

From: Ulrich Eckhardt on
srp113 wrote:
> I see that inheritance allows the paradigm of "programming to
> interface" with ease. [...] seems to allow programming to interface
> naturally because of dynamic binding.

Yes, this is commonly called polymorphism.

> While templates clearly allow reuse: put common code into
> unspecialized template class and each specialization can have its own
> specialized code that could call the common code from unspecialized
> class, they dont seem to "allow programming to interface paradigm",
> because they are bound at compile time, I cannot have an abstract base
> class (interface) initialized with different versions of specialized
> templates.

It is very difficult to guess what you are trying to express in this single
sentence. Anyway...

You talk about class templates, which are not the only place where templates
are used. There are also function templates, like std::sort or
std::make_pair.

Then, you say that a specialization can access code from the unspecialized
class. This is only so far true as anyone can access the code, i.e. that it
is public and class-static. There are often class templates that never have
a "common" implementations, just like there often are class templates that
never are specialized.

Then, you claim that they don't allow programming to interface paradigm.
Actually, the reverse is true. Take a look at e.g. std::sort. It takes a
sequence described by two random-access iterators IIRC. In other words, it
is the interface of a random-access iterator that it is written for.
However, RA iterators don't share a common baseclass but only interface
requirements, which are checked at compile time. This is also known as "duck
typing".

BTW: Inheritance is sometimes called run-time polymorphism while templates
are called compile-time polymorphism, exactly because they achieve very
similar things only at different times.

> This seems to be one reason why inheritance would be
> preferred over templates.

Both are tools, like OOP or C++. Tools have cases where their use is
appropriate and cases where other tools are better suited. In that light,
your claim is simply wrong.

Uli


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