Re: Polymorphism without virtual in C++
On 8=E6=9C=888=E6=97=A5, =E4=B8=8B=E5=8D=884=E6=97=B617=E5=88=86, James Kan=
ze <james.ka...@gmail.com> wrote:
On Aug 7, 12:02 pm, feel <feel...@gmail.com> wrote:
On Aug 7, 4:55 pm, James Kanze <james.ka...@gmail.com> wrote:
[...]
This sounds more like letter-envelope than like compilation
firewall. But I'm not sure I've fully understood it. (The
letter-envelope idiom is used to make a class with value
semantics behave polymorphically.)
Yes, it's just like that. But the difference is:we have to work on
many kind of Envelops.
In classic letter-envelop, we can hide the real data
deifinition. but if we have to work on a class heirarchy, for
example:
Entity
^
|
Curve
^
|
Line
In this case, the real data is in Line, but we have to catalog all the
line's method into Entity, curve.
Then we can work on all kind of entity or curve.In a summary, we have
two requirement:
1 data hide, different data implementation.
2 class heirarchy.
I'm not sure I understand. How is this different from the
classical letter-envelope? You declare all of the functions in
Entity, virtual, with an implementation which just forwards to
the letter class.
Or is it that the real "envelope" (which defines the interface)
is Curve, and Entity is just some sort of generic holder
(something like boost::any)? In that case, I'd implement Curve
as a true letter envelope, and provide for some sort of dynamic
casting to get a Curve from Entity, e.g.
class Entity
{
public:
template< typename Envelope >
operator Envelope() {
return Envelope(
dynamic_cast< Env=
elope& >( *myLetter ).clone() ) ;
}
private:
Entity* myLetter =
;
} ;
(Note that this will throw std::bad_cast if Entity isn't really
the requested type.)
So if I have an Entity, and want to use it as a Curve (although
it is really a Line, of course):
Curve c = static_cast< Curve >( entity ) ;
(It's a bit wierd in that you need to use static_cast in order
to get a dynamic_cast. Perhaps a named function would be
preferable to the type conversion operator.)
--
James Kanze (GABI Software) ema=
il:james.ka...@gmail.com
Conseils en informatique orient=C3=A9e objet/
Bera=
tung in objektorientierter Datenverarbeitung
9 place S=C3=A9mard, 78210 St.-Cyr-l'=C3=89cole, France, +33 (0)1 30 23 0=
0 34- =E9=9A=90=E8=97=8F=E8=A2=AB=E5=BC=95=E7=94=A8=E6=96=87=E5=AD=97 -
- =E6=98=BE=E7=A4=BA=E5=BC=95=E7=94=A8=E7=9A=84=E6=96=87=E5=AD=97 -
Thank you for your reply. I think you are right. I do not use virtual
functions as interface
because the size of object. Saying line, we can put two points as data
implementation. But if
put many virtual functinos into class, we have to get a bigger object
than that object should be:
only two points!Object's size is very important in geometry class
design.
Pimpl can make sure the object's size is suitable for this
requirements.
Polymorphism means in this case is like this: we can call curve's
getLength() function to get curve's
length. but for different kind of curves, we have to implementation
different method to compute it.