Re: inheritance, list of objects, polymorphism
On 15 Dec, 12:15, Michael Doubez <michael.dou...@free.fr> wrote:
On 15 d=E9c, 11:26, barbaros <barba...@ptmat.fc.ul.pt> wrote:
Back to my code. I have a base class "Expression" and derived
classes "ExpressionSum", "ExpressionProduct", "ExpressionPower" and
so on. For instance, xy+yz+z is an ExpressionSum of two
ExpressionProduct and an Expression. The class ExpressionSum is
implemented as a list of terms to sum up. These terms should be any
other Expressions (Products, Powers, or mere Expressions). The
problem is, when I call ExpressionSum::add(expr), expr being an
ExpressionProduct, it looks like expr is first converted to a mere
Expression and then added to the list.
Yes, you stores Expression values. You should store Expression
pointers which raises the problem of deep copy. It is usually solved
by implementing a 'virtual Expression* clone ()' operation.
Another alternative is to use the Envelope/Letter idiom.
Which just hides the cloning. If Expression objects are immutable
(and
they probably should be), then a much simpler solution would be to use
reference semantics (i.e. pointers) everywhere. Depending on the
application, this might even be a case where shared_ptr is
appropriate---an expression tree is just that, a tree, and can't have
cycles. (There are other solutions, with better performance, but they
generally require more work.)
[snip]
class Expression {
[snip]
class ExpressionProduct : public Expression {
[snip]
class ExpressionSum : public Expression {
public:
list<Expression> terms;
Here you have slicing of your objects.
If you make Expression virtual pure, you won't be able to compile your
code.
General rule: assignment and external copy don't work well with
inheritance. (In my own code, I've gradually been introducing a
PolymorphicObject base class, with a virtual destructor and a private
copy constructor and assignment operator. With the rule that classes
designed to be used polymorphically should inherit from
PolymorphicObject.)
--
James Kanze