 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Amanjit Gill
Guest
|
 Posted: Sat Aug 12, 2006 4:30 am Post subject: Static polymorphism and the LSP principle |
 |
|
I am trying to do Static polymorphism with templates while mainting
the OOP philosophy (for those cases where a virtual method dispatch is
too expensive).
template<class DERIVED_>
struct IAlgorithm {
void calc() {
static_cast<DERIVED_*>(this)->calc();
};
};
struct SimpleAlg : public IAlgorithm<SimpleAlg> {
void calc() {
}
};
struct ComplexAlg : public IAlgorithm<ComplexAlg> {
void calc() {
};
};
I would like to store f.e. an vector<boost::any> list of instances of
classes that conform to the IAlgorithm interface- i.e. that contain
both SimpleAlgs and ComplexAlg - and the list should be completely
run-time alterable with regard to the order of items. Of course I
want clients only to use the IAlgorithm<> interface contract (LSP
principle).
I have read a paper called SCOOP ( "Static C++ Object-Oriented
Programming (SCOOP) Paradigm Mixing Benefits of Traditional OOP and
Generic Programming", by Burrus, Duret-Lutz, et all) which shows one
approach to this problem, but haven't worked through it completely.
Best approach to solvie this problem?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
 |
Greg Herlihy
Guest
|
| Posted: Sun Aug 13, 2006 2:09 am Post subject: Re: Static polymorphism and the LSP principle |
|
|
Amanjit Gill wrote:
| Quote: | I am trying to do Static polymorphism with templates while mainting
the OOP philosophy (for those cases where a virtual method dispatch is
too expensive).
template<class DERIVED_
struct IAlgorithm {
void calc() {
static_cast<DERIVED_*>(this)->calc();
};
};
struct SimpleAlg : public IAlgorithm<SimpleAlg> {
void calc() {
}
};
struct ComplexAlg : public IAlgorithm<ComplexAlg> {
void calc() {
};
};
I would like to store f.e. an vector<boost::any> list of instances of
classes that conform to the IAlgorithm interface- i.e. that contain
both SimpleAlgs and ComplexAlg - and the list should be completely
run-time alterable with regard to the order of items. Of course I
want clients only to use the IAlgorithm<> interface contract (LSP
principle).
|
Boost::any is dynamically polymorphic (it uses a virtual method to
confirm its stored type) - and in fact the container of algorithms as
described would require runtime polymorphism. So if the "problem" is
how to implement runtime (dynamic) polymorphic behavior using only
efficient, compile-type polymorphism - then a solution is unlikely to
be forthcoming. There is after all a tradeoff between the low-cost
efficiency of static typing versus the power (and relatively higher
price) of dynamic typing.
So the challenge here is for the program to make the right tradeoff: to
use compile time polymorphism where possible and runtime polymorphism
when needed. And certainly having a set of classes capable of both
static and dynamic polymorphic behavior would be especially helpful in
attaining this optimal balance.
| Quote: | I have read a paper called SCOOP ( "Static C++ Object-Oriented
Programming (SCOOP) Paradigm Mixing Benefits of Traditional OOP and
Generic Programming", by Burrus, Duret-Lutz, et all) which shows one
approach to this problem, but haven't worked through it completely.
|
The paper describes a clever scheme to implement compile-time
polymorphism - not run-time polymorphism. Furthermore, the paper cites
as one of SCOOP's drawbacks the fact that it produces "unusual code,
unreadable by the casual reader." So I would suggest sticking with the
current Algorithm class template (at least it's readable) - but with a
few changes: The first change I would suggest would be to remove the
algorithm types themselves from the class hierarchy. The only
requirement that this program imposes upon its algorithmic types is
that each implements a calc() method. There is no necessity that they
be otherwise related or have anything else in common. So instead of
having the algorithm type inherit from the Algorithm class template, it
would simply serve as one of the Algorithm class template's data
members:
template <class T>
struct Algorithm
{
T mImpl;
Algorithm(T impl) : mImpl(impl) {}
void Calc()
{
mImpl.Calc();
}
};
To attain the runtime polymorphic behavior that a container of diverse
algorithms would require, the Algorithm class template would inherit
from a base class, AbstractAlgorithm. AbstractAlgorithm would implement
a Non-Virtual Interface (NVI) like so:
struct AbstractAlgorithm
{
void Calc()
{
DoCalc();
}
protected:
virtual void DoCalc() = 0;
};
while DoCalc() in Algorithm would simply call its own Calc() method.
template <class T>
struct Algorithm : public AbstractAlgorithm
{
...
protected:
virtual void DoCalc()
{
Calc();
}
};
In this way, calls to Calc() are either statically dispatched for
Algorithn objects whose parameterized algorithm type is known at
compile-time - or dynamically dispatched for those Algorithm objects
whose specific algorithm can vary and therefore has to be ascertained
only at runtime.
Greg
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Amanjit Gill
Guest
|
| Posted: Sun Aug 13, 2006 2:26 am Post subject: Re: Static polymorphism and the LSP principle |
|
|
Hi, Amanjit ;-)
| Quote: | I am trying to do Static polymorphism with templates while mainting
the OOP philosophy (for those cases where a virtual method dispatch is
|
check out this url (or google comp.lang.c++.moderate for "Polymorphism
and Template Based Design", Greg Herlihy)
http://tinyurl.com/huobh
Bye...
{ The shortcut link above goes to a relevant clc++m thread in Google's
Usenet archive. -mod/aps }
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Alberto Ganesh Barbati
Guest
|
| Posted: Sun Aug 13, 2006 8:32 pm Post subject: Re: Static polymorphism and the LSP principle |
|
|
Amanjit Gill ha scritto:
| Quote: | I am trying to do Static polymorphism with templates while mainting
the OOP philosophy (for those cases where a virtual method dispatch is
too expensive).
template<class DERIVED_
struct IAlgorithm {
void calc() {
static_cast<DERIVED_*>(this)->calc();
};
};
struct SimpleAlg : public IAlgorithm<SimpleAlg> {
void calc() {
}
};
struct ComplexAlg : public IAlgorithm<ComplexAlg> {
void calc() {
};
};
I would like to store f.e. an vector<boost::any> list of instances of
classes that conform to the IAlgorithm interface- i.e. that contain
both SimpleAlgs and ComplexAlg - and the list should be completely
run-time alterable with regard to the order of items. Of course I
want clients only to use the IAlgorithm<> interface contract (LSP
principle).
|
As you have only two types (SimpleAlg and ComplexAlg) I would consider
using boost::variant<SimpleAlg, ComplexAlg> instead of boost::any. If I
understand what you are trying to do, you could achieve that easily by
provide a suitable static visitor.
Ganesh
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Amanjit Gill
Guest
|
| Posted: Thu Aug 17, 2006 3:20 am Post subject: Re: Static polymorphism and the LSP principle |
|
|
Greg wrote
| Quote: | In this way, calls to Calc() are either statically dispatched for
Algorithn objects whose parameterized algorithm type is known at
compile-time - or dynamically dispatched for those Algorithm objects
whose specific algorithm can vary and therefore has to be ascertained
only at runtime.
|
Thanks Gred, I also found an old post of yours with google. Actually, I
think when runtime polymorphism is needed, virtual methods are the way
to go, especially since the stepanov "abstraction" benchmark shows
minor penalities with newer compilers.
I would use templates only to create those tight, performant classes
(probably composed by using policy based design) and use the virtual
method polymorphism in all other cases.
Thanks for your insight.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
