How to access inherited members from object

[jamie]

Using Inherited "name" allows you to access these items from within the class they live in, how to access these outside the class?

 Lets say i have var of a class instance and need to access a inherited class member?

Example:

   MyClassInstance.Inherited.ClassMember.

I dont think Casting will work.

[cdbc]

Hi
Have you tried:

  TMyClassParent(MyClassInstance).ClassMember.
I've seen that done with TStrings(someStringlistInstance).Ithinkitwasindexof
Regards Benny

[LeP]

I don't think what you asked has some logical reasons ...
I mean, if you use Create constructor (for example) you tipically use "inherited" ... but call it from external is not sense.

[Thaddy]

The whole point of object orientation, apart from inheritance, is hiding code you do not need.
There are some "hacks" like declaring a class with the same structure and then cast to that, but different visibility, but if something is either strict private or private it should not be accessible. Private (not strict) members are accessible in the same unit but not elsewhere. Strict private is not even accessible in child classes but will remain active when inherited. You can't see that code unless access properties are supplied with at a minimum have protected visibility.

If there is a solid reason for what you want, I am happy to write an example.

[Martin_fr]

If it is NOT virtual, then casting the class might work.

If it is VIRTUAL, then => you can't.

The usual workaround is to have a method CallInheritedFoo, that contains the inherited call.
Mind, that even inside the class, you can only go up ONE level.


I have not tried, but you may be able to get the address of the method on the class, and then use that and TMethod to build yourself a pointer to the function, and that then you could call (if properly typed, to pass the correct args)

[jamie]

Ok, What I did for the time being is to place a Busy Constant trap in there because it was causing a Stack flood due to an instance of that class calling the member which then called the Inheritance but then followed through calling backwards a class that was calling that again, which simply caused an reentry.

  This is a translated piece of C++ code which was inserting the inherited class on the fly. I know you can do this in C++ classes, call the inherited class directly, even if they are VIRTUAL declared and yes, these are VIRTUAL in nature.


  The Busy flag works because it only allows the call to the inherited section of code and then checks the BUSY flag and then exists if its set, otherwise it sets it to TRUE and at the end, will clear it back to False.

    The C++ code was specifying the ClassName::FunctionName which is an inherited class of the main class, I guess FPC does not allow using the Inherited operation in remote code, even when that inherited function is not protected.

Jamie


 

[Thaddy]

With virtual methods, the hack I suggested applies. If not, it is like Martin wrote.
Since you are translating from C++: are you translating or making an interface?
If you are only translating, your code is wrong, if you are writing just an interface we can help if you do not know how to write a class cracker yourself. (You probably can)

Plz note that memory layout from C++ compilers differ per C++ compiler, since that part is NOT part of the C++ language and as such undefined: in such case you need to "flatten", e.g translate to C, not C++.
GNU C++ and BC++ are easy. Others may be more difficult if the interface part of the VMT does not start at 0.

But I guess you are not interfacing: in that case simply make the methods all virtual.

See what me (small credited part) and the late Rudy Velthuis wrote about that 20+ years ago here:
http://www.rvelthuis.de/articles/articles-cppobjs.html
This still applies, just in case.

You can still access or change non-virtual members by redirecting them by use of trampolines.
Which is also not too difficult but not recommended.

Just a side note: if the methods you are after are NOT virtual they are not really OOP anyway.

If you show us some almost compilable code, that would help: the solution may be much easier than the scenario I described above. Simply the class cracker, because that always works without inheritance issues.

Last note: inheritance can not cause stack problems: they are one way and one way only even if riding the inheritance ladder to a root. A base class can not access nor have knowledge of anything in the future. And that is language independent.