On May 13, 2:52 pm, Jess <w...@hotmail.com> wrote:
On May 12, 11:03 pm, James Kanze <james.ka...@gmail.com> wrote:
Many thanks. Regarding your example:
class A
{
public:
A* clone() const
{
A* result = doClone() ;
assert( typeid( *result ) == typeid( *this ) ) ;
return result ;
}
Why do you need to check typeid?
To catch post-condition violations.
"clone" isn't virtual, then will the
correct version be called if I try to "clone" a B object?
"clone" isn't virtual, because the only correct version is in
the base class. "clone" calls a virtual function, "doClone" to
do the actual work.
This is the usual C++ implementation of programming by contract.
Is it true that if a non-virtual function (here "clone") calls
a virtual function (doClone),then the caller function is
automatically virtual?
No. The whole point of the exercise is that it is impossible to
call the virtual function without the post-condition checks.
private:
virtual A* doClone() const
// Except that usually, this will be pure virtual.
// It's fairly rare to have virtual functions in a
// base class which aren't pure virtual.
{
return new A( *this ) ;
}
} ;
Why is it necessary to have another virtual function here that is also
private? What if I put this line of code into "clone()"?
It won't work, because clone() isn't virtual.
class B
{
private:
virtual A* doClone() const
{
return new B( *this ) ;
}
} ;
If I have a B object "b", then if I do "b.clone()", then "A"'s clone()
method will be called, is it right? I guess what happens next is that
A's clone() calls "doClone()", since this is virtual, then B's
doClone" is called.
Right. A defines a contract. In this case, we've done nothing
in B to define a new contract, so A's contract still holds.
Which means that we start by calling a function in A, in order
to enforce the contract.
In practice, this is the usual situation. I'd guess that in
something like 90% of the cases involving inheritance, you
define a contract in a base class, and inherit, one level deep,
to provide different implementations. Practically, the only
time the user sees the derived class is when he constructs one;
all other accesses are through the base class.
There are cases, however, where the derived class wants to
provide an extended contract. Thus, for example, B might decide
to offer an extended guarantee for clone()---not just an A*, but
a B*. (Clone is actually a pretty poor example for this, since
the post-condition in A says that the pointer returned by
B::clone will point to a B. But the principle applies in
general.) In such cases, B is free to provide a new non-virtual
public function, which validates the new contract. Users who
know they have a B, and want to use the extended contract,
dynamic_cast their pointer to B*, and use it.
I'm still not sure why doClone is needed. Would it work if I do:
class A
{
public:
virtual A* clone() const
{
A* result = new A(*this) ;
assert( typeid( *result ) == typeid( *this ) ) ;
return result ;
}
};
class B
{
B* clone() const
{
return new B( *this ) ;
}
} ;
It would work, but what's the point. What happens if you
derived C from B, and forget to override clone. Everything
compiles fine, but anytime you clone a C, you actually get a B.
Your post condition is violated, and you never notice it.
(Actually, of course, you will notice it further down the road.
When you end up trying to understand why you have a B, when you
should have a C.)
--
James Kanze (GABI Software) email:james.ka...@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
virtual functions don't help. For example, I may have a function "f"
object is really A or B before doing anything. Suppose I don't have
virtual functions. In this case, how can the function "f" know if