Thread: Inheritance Problem

Oh no the big guy(Delphi) is BROKEN too, how sad.

Code:

interface
type
  TNode = class
    protected fTest :String;
    public property Test: String read fTest;
  end;
  TLinkedNode = class(TNode)
    public procedure Test(Node: TNode);
  end;
implementation
procedure TLinkedNode.Test(Node: TNode);
begin Node.fTest := 'Hello world!'; end;
end.

var
  Node  : TNode;
  Linked: TLinkedNode;
begin
  Node := TNode.Create;
  Linked := TLinkedNode.Create;
  Linked.Test(Node);
  Writeln(Node.Test);
end;

I just figure it out this is as a matter of package/unit visibility, since C++ is only know straightforward name collision solver namespaces.

However the problem can be solved in nasty way(which maybe possible in C++): If and if only there is an ability to access parameter's base class to call the non-overriden method -- IF the parameter IS LinkedNode, otherwise we don't care.
EDIT:
Sorry, I will just giving you my simplified abstract problem. I usually use Stack, Node, LinkedList, Point or Rectangles which in reality much much overcomplicated :P

Delphi is broken too.
C++ isn't stupid nor broken. You are putting it into use the wrong way.
At this point, it seems that you just want to coerce it to work the way you want, and I say that's not a good idea. You should just quit C++ if that's your attitude.
What you want is to make LinkedNode a friend of Node. This is exactly what Java and Delphi has done for you. But I doubt it's a good design overall.

A better design, I think, is to have a common base class and derive your functionality to Node and LinkedNode. But Node and LinkedNode should be separate, ie LinkedNode should be a Node.
No friends. No compile errors. No horrible workarounds.

Originally Posted by audinue

I just figure it out this is as a matter of package/unit visibility, since C++ is stupid enough to know that but straightforward name collision solver namespaces.

The second part of your sentence is unintelligible to me. This is just a matter of language rules depending on how language designers interpret theory and consider practice. I tend to think that C++'s interpretation is unnecessarily strict since the damage is done anyway once you have non-private member variables, but that does not mean that C++ "isn't mature enough to handle high level OOP concepts". You really should stop making such troll-like comments until you are more mature in your understanding of the programming language that you are commenting on.

Originally Posted by audinue

However the problem can be solved in nasty way(which maybe possible in C++): If and if only there is an ability to access parameter's base class to call the non-overriden method -- IF the parameter IS LinkedNode, otherwise we don't care.

The "access parameter's base class to call the non-overriden method" part is easy:

Code:

virtual void setNext(Node *next) {
    if(next) {
        next->Node::setPrevious(this);
    }
    Node::setNext(next);
}

If you actually want to have it behave depending on the actual type of the object that the next parameter points to, then you will incur the runtime penalty of a type check:

Code:

virtual void setNext(Node *next) {
    if(next && dynamic_cast<LinkedNode*>(next) == 0) {
        next->setPrevious(this);
    }
    Node::setNext(next);
}

Laserlight rocks! You rule!

Thank you and sorry for my bad attitudes.
I'm just stressed enough solving somekind of heavy AI program which is unsuitable for any language but C++ for performance controls and managements.

Laserlight! Thank you!

EDIT:
Elysia's suggestion about separating Node interface, Node and the linked one is very good, if the states put in the implementing classes -- which leads to code rewriting and duplication.