Re: Downcasting base-class objects to a derived-class
On Dec 7, 12:25 am, vsk <vmi...@gmail.com> wrote:
Thank you all very much!
Your responses are very generous, and I've manged to get my code to
compile and work.
Few things I want to respond to;
The major problem with the vtable is because you did not provide a
base implementation of any of your IExpression virtual functions.
I had already implemented all virtual functions in my derived-class.
Yes, but you did not provide a *base* implementation.
In the example below, a() is a member function that can be optionally
overridden by a derived class, b() is a member function that *must* be
overridden by a derived class, and c() is a member function that can
not be overridden by a derived class:
Java, as an interface:
public interface Something {
// no such thing as a() in an interface
public void b (); // pure virtual, abstract is implicit
// no such thing as c() in an interface
}
Java, as a class:
public class Something {
public void a () { }
public abstract void b (); // pure virtual
public final void c () { }
}
C++:
class Something {
public:
virtual void a () { }
virtual void b () = 0;
void c () { }
};
The same rules apply in C++ as in Java. The a() function is just a
plain virtual function. In both Java and C++ classes a base
implementation *must* exist. The b() function is a pure virtual
function. All of your original IExpression member functions were just
virtual, not pure virtual (i.e. "abstract" in Java). Therefore, just
like plain virtual functions in Java, you must have a base
implementation. You must have both the base IExpression
implementation, and derived implementations can optionally override
them.
In Java, all functions in an interface are implicitly abstract, that
is implicitly pure virtual, meaning that this C++ class does *not*
express the same thing as a Java interface:
class IExpression {
virtual ~IExpression ();
virtual something ();
virtual another ();
};
Those are regular virtual functions. They are *not* pure virtual
functions. Therefore the implementations of those for IExpression
*must* exist, regardless of what your derived classes implement. Java
interfaces specify pure virtual functions, and so the closest thing
you can do is also use pure virtual functions in your base class:
class IExpression {
virtual ~IExpression () { } // no analog in Java interface
virtual something () = 0; // PURE virtual
virtual another () = 0; // PURE virtual
};
And now, just as with "abstract" Java class methods, and just as with
all Java interface methods, the methods something() and another() in
that C++ class are also pure virtual functions.
Read this: http://en.wikipedia.org/wiki/Virtual_function
2) The fact that you are using a cast in the first place. After all,
according to the above, the number '5' is not equal to the expression '=
2
+ 3'. Is that really what you want?
No, it isn't. That's why there's an IExpression::simplify(). It
matches expressions against 36 different rules to eliminate redundancy
and make IExpressions cleaner.
Your code didn't express that. Your function:
bool Number::equals (IExpression &that) { ... }
Always returned false if "that" wasn't a Number. Meaning for a client
to get the expected results, they'd have to be sure to always simplify
() the expression *before* calling equals(), in the hopes that "2 + 3"
would get reduced to a Number.
// I'm making up these classes and constructors:
Number n(5);
Sum sum(Number(2), Number(3));
n.equals(sum); // this would be false
n.equals(sum.simplify()); // this would be true
That's somewhat counter-intuitive, IMHO, but it might be appropriate
for your application.
An IExpression can be either a primitive, unary, or binary operation
(0, 1, or 2 arguments in the constructor). Primitives are Numbers and
Vars. Unary includes Sin, Ln, Neg, etc. Binary includes Sum, Product,
Quotient, Exponentiation etc.
3) C++ and Java have very different philosophies, especially when it
comes to object creation a straight port probably isn't wise. You would
learn more by attempting to re-implement the behavior of the Java
program in C++ without trying to directly port the code.
That's what I meant, sorry.
I think I grasp these concepts now.
You need to read up on C++ inheritance, and on the difference between
non-virtual, virtual, and pure virtual functions in general (concepts
that apply to many languages that support inheritance). You also need
to forget about the Java "interface". While you can do conceptually
the same things in C++ that you can with interfaces in Java, the
interface construct has no direct analog in C++. The closest thing you
can get is a C++ class with nothing but pure virtual member functions
(and a virtual destructor).
HTH,
Jason