Hey everyone-

I apologize ahead of time, im gonna be putting up a few posts today, i have a good amount of free time, and there are several questions that have been rolling around in my head.

So i had a questions relating to c++ classes, inheritance, and dlsym.

1) So my first question relates to c++ classes and inheritance. If i understand correctly i can make a class, well call it MY_CLASS for now. I can then create another class called MY_NEW_CLASS and have it inherit the properties and methods of MY_CLASS. This part i follow just fine. My question is, from what i have read is i can pass an instance of MY_NEW_CLASS as a parameter to a function that would normally only accept MY_CLASS because MY_NEW_CLASS inherits from MY_CLASS. Is this correct?

And assuming that is correct. Im also assuming that i can create an instance of a MY_NEW_CLASS and return it from a function that is only expecting a MY_NEW class to be returned.

And assuming all that is correct, assuming when the MY_CLASS variable is returned from a function that was actually passed a MY_NEW_CLASS as long as i cast the returned variable properly to a MY_NEW_CLASS it would still function normally as my new class and not of been pillaged and raped by being returned as a MY_CLASS correct?

I know this may seem a bit basic, but i just want to make sure i grasp the concept before i go writing this huge chunk of code.

2) Now for the second part. Lets say that MY_NEW_CLASS is not part of my original program but still inherits from MY_CLASS. If i load up a shared object into my program that makes use of MY_NEW_CLASS can it still pass MY_NEW_CLASS as a parameter of MY_CLASS to functions, and be returned by functions without mangling since the original program knows nothing of MY_NEW_CLASS?

Thanks in advance.

_-Menser-_

http://www.faqs.org/docs/Linux-mini/C++-...
http://www.linuxjournal.com/article/3687

Thank you tyche-

And for anyone who doesnt want to read the articles he linked who may have the same questions.

1) Yes my assumptions on how the variables were handle when passed through functions and back from functions were correct.

2) Yes, the program will handle the passing around and what not of MY_NEW_CLASS with no problems as long as MY_NEW_CLASS inherits from a class the original program is aware of. The original program however could not make use of the extended properties and methods of MY_NEW_CLASS since it is unaware of it and can only handle it as MY_CLASS.

Thank you once again tyche.

class MyClass
  def jump
    p 'boing!'
  end
end

class NewClass < MyClass
end

class ClassWithNoLegs
end

def make_class_jump(klass)
  klass.jump if klass.respond_to?(:jump)
end

new = NewClass.new
old = MyClass.new
noleg = ClassWithNoLegs.new

[new, old, noleg].each {|x| make_class_jump x}

That is pretty tricky to do in C++, no?

Well, yeah, it isn't trivial to determine if an object in c++ responds to a method, but there are ways. So I assume the only line of code there that's important is

module Meh
  def make_this_jump
    jump if respond_to?(:jump)
  end
end

Yeah, the rest was just for explanation.



That was the part that caught my interest. My median nerve cringes at the thought of something like this requiring a huge chunk of code.


EDIT: @Runter - DH explained it to me once, but I still couldn't do it. =)

More or less. In C++, there is the caveat that you can pass objects of the derived type into functions expecting the base type, but this causes slicing (where the information for the derived type is literally sliced off the object that is passed. This should be avoided. Therefore, it is probably better to say that you may use a pointer or reference to an object of the derived type (in your case MY_NEW_CLASS) wherever a pointer or reference to an object of the base type (MY_CLASS) is expected.

Further reading: http://en.wikipedia.org/wiki/Liskov_subs...

I'll be assuming you're using pointers and references from now on.



Yes. Also beware returning pointers or references to local objects. They will want to be allocated with new to ensure that their lifetime exists beyond the scope of the function.



Yep.



Yes. I've done this personally. It's a very useful technique that enables hiding a concrete implementation behind an abstract interface while using shared objects to supply the module concept.

I think you're limited to pointers, though, because putting extern "C" to get rid of the C++ name mangling means that you can no longer use references.

To Chris Baily et al: in C++, we'd probably use the visitor pattern for that. Not something I've had a great deal of use for, but it's there for when you need it.

For C++, try RTTI: http://en.wikibooks.org/wiki/C++_Program...

Heya-

@Runter - Lol i didn't mean a huge chunk of code to do just that. I just ment this huge chunk of code i would have to rewrite to support the base, and extended class system setup i want for my modules. I wanted to make sure they performed as expected in said scenarios before i began that rewrite.


@Kaz- Yup ment pointers. Everything is pretty much passed around by pointer. Good call on the slicing, i wasn't very clear what i ment in my other follow up post and someone who read it later on with a similar situation might not of realized what i ment and experienced that.

@oenone - Interesting read but wasnt exactly on point for what im talking about. I will know the type of object im dealing with, and subsequently know either the sub or super type of it so that wasnt the issue. I was simply stating the main program, not having been compiled with references to the super class can not actually handle the class as the super class, but simply as the base class.


Thanks again folks
_-Menser-_

Actually that was me. Runter knows better =)

Beware how you trifle with your marvelous inheritance, this great land of ordered liberty, for if we stumble and fall, freedom and civilization everywhere will go down in ruin.