Page 1 of 1

: N00b trying to handle classes in C++

Posted: Sun Aug 14, 2005 4:53 am
by amee2000
Hi!

I have a class in one of my programs and pass the pointer to an instance of this class to another program (which is compiled with the "class {...}" in one of the header files - no code, only prototypes). Can I use this pointer to call functions in the class, given that I can access the memory, where the other program is?

Re:: N00b trying to handle classes in C++

Posted: Sun Aug 14, 2005 5:24 am
by AR
The program doing the calling needs the code to be linked in (either statically or dynamically) unless you are calling the functions manually through a call table of some sort.

If you fulfill the above requirement then you can simply have:

Code: Select all

MyClass *myclassptr = reinterpret_cast< MyClass* >( pointer_to_wherever );

Re:: N00b trying to handle classes in C++

Posted: Sun Aug 14, 2005 9:36 am
by durand
Oh.. are you trying to pass a pointer between programs?

That will require that the object's data be in the exact same location in both programs' memory space. Is it? If so, then the reinterpret_cast will work. I mean, if what you said is true and the memory is in exactly the same place - "given that I can access the memory, where the other program is" - then it sounds like correct.

However, just in case and if not, you will actually want to send the data that the pointer points to - not the pointer itself. So your IPC methods will need to send more than just sizeof(void*) and should send sizeof(MyClass) bytes.

Maybe this will work: (imaginary code)

.. on the sender side ..

Code: Select all

MyClass *myclassptr = new MyClass();
send_msg( other_application, myclassptr, sizeof(MyClass) );
.. on the receiver side ..

Code: Select all

void* buffer = malloc( sizeof(MyClass) );
receive_msg( buffer, sizeof(MyClass) );
MyClass *myclassptr = reinterpret_cast< MyClass* >( buffer );
Also, I believe that with C++, class code and object data are kept separate so when you're sending the myclassptr, you're actually just sending the required data that makes that particular object instance unique. You're not wasting energy and sending any code.

Re:: N00b trying to handle classes in C++

Posted: Sun Aug 14, 2005 10:10 am
by amee2000
But if the data does not contain a pointer the the code of that class, I will need to have the code in both programs. That is exactly what I don't want.

Re:: N00b trying to handle classes in C++

Posted: Sun Aug 14, 2005 12:50 pm
by durand
Ah, okay. Unfortunately, you do need the code in both programs then.. Either by compiling it in or using a library you compile against or link against.

C++ isn't really "object orientated" in the strictest sense. It's more object-like. When you start to do fancy stuff like you're trying to do, then you start to show the failings of the language versus the concepts it tries to implement.

If you had:

Code: Select all

class MyClass
{
  public:
     void print()
     {
        printf("%i\n", my_data );
     }

  int my_data;
};

MyClass *bob = new MyClass();
You're actually just creating a little bit of memory where the object's data is stored. The actual code of the class is kept in another place and there's only one copy for all objects. (perhaps in the library). MyClass::print() gets compiled kinda like:

Code: Select all

MyClass::print()
{
   printf("%i\n", (*this).my_data );  // or this->my_data
}  
And whenever you call bob->print(), the application is actually setting "this" to point to the bob data location and running the class code.

Yup. So, so when you instantiate an object in C++, you're just created a data region. Code is elsewhere. If you pass the object/pointer to another application, then the code does not go with. The other application will not know how to use the data. No methods will exist.



I think Objective-C is far more object oriented than C++. With Objective-C, you can actually list what methods the objects expose and you can call them that way.. without "hard-coding" it all.

I'm not sure if you can do that with Java but I doubt it.


Disclaimer: I could be wrong.

Re:: N00b trying to handle classes in C++

Posted: Sun Aug 14, 2005 1:32 pm
by Colonel Kernel
durand wrote:C++ isn't really "object orientated" in the strictest sense. It's more object-like.
No, C++ definitely is an object-oriented language -- it just happens to be a very "static" one by virtue of its minimalist run-time environment.
I think Objective-C is far more object oriented than C++. With Objective-C, you can actually list what methods the objects expose and you can call them that way.. without "hard-coding" it all.

I'm not sure if you can do that with Java but I doubt it.
You can, actually. The feature you're describing is "reflection", and Java and .NET both have it. I'm sure lots of other dynamic languages have it too. The only thing in C++ that comes even close is run-time type identification, but it's pretty weak in comparison.

You can even do what you describe with late-bound COM objects, if you're so inclined... :P

Back to the OP's problem -- It sounds to me like you need something like COM or Corba, both of which I think are rather yucky, but they would do the job.

More importantly, why do you need to pass an object between programs in the first place...?

Re:: N00b trying to handle classes in C++

Posted: Sun Aug 14, 2005 6:35 pm
by amee2000
I had the idea of implemeting interfaces between modules this way but there seem to be better ones...

A module consisting of a class (or possibly more than one) and initialization/finalization code to create instances would make it possible for the module load itself multiple times without actually doing so by creating new instances of the class. but to allow other modules to access the classes I would at least need to pass the pointers around.

Re:: N00b trying to handle classes in C++

Posted: Sun Aug 14, 2005 10:35 pm
by Colonel Kernel
amee2000 wrote: but to allow other modules to access the classes I would at least need to pass the pointers around.
If those modules are in the address space, then passing interface pointers around should be ok. If you're passing between address spaces, you'll need to set up proxy objects and marshal method parameters over some kind of IPC (in other words, you'll be re-implementing a lot of COM, so why not study how it works...?)

AFAIK, there really isn't a better way of doing it if you have to stick with C++.

Re:: N00b trying to handle classes in C++

Posted: Sun Aug 14, 2005 11:14 pm
by AR
I get the feeling this is a carry over from your kernel module questions from the OS Dev forum. I believe you will find it much easier to just implement the modules in C, you will have more control this way, instancing can be provided for by the typical "instance struct pointer parameter" method.

You can build a reflection engine if you want to try but COM Inter-Process Calls will probably be more straightforward if you really want to use classes.

Re:: N00b trying to handle classes in C++

Posted: Mon Aug 15, 2005 3:54 am
by amee2000
It is. I thought more C++ than OS related questions would be better placed here.
...instancing can be provided for by the typical "instance struct pointer parameter" method...
wouldn't that be quite the same like the "this" pointer, only that I need to take care of it myself? Using real classes I can get that handled by C++

Re:: N00b trying to handle classes in C++

Posted: Mon Aug 15, 2005 6:10 am
by AR
Yes it is equivalent to a "this" pointer. C++ was not designed to do what you want it to, the data can be transfered but the code to manipulate the data must also exist in the manipulators symbol table (ie. be linked either statically or dynamically).

The only other alternative that I can think of at the moment is a hack, you can compile the kernel to ELF, dynamically link against a library containing the class then during runtime you can hack the GOT/PLT to point to the different modules' class functions - this should work but I wouldn't consider it to be a good idea. (You could do the same thing with other executable formats as well, eg. rewriting the thunks in a PE binary)