Archived

This forum has been archived. Please start a new discussion on GitHub.

Question about serialization of inherited classes

I've got a quick question pertaining to how derived classes are handled by Ice; lets say I have a couple classes defined in Slice that look something like this: (I apologize for any syntax errors)

class MyCommand {
int CommandId;
};

class MyClass {
void handle(MyCommand command);
};

Now in my actual C++ code, lets say I have some classes which are not defined with slice that I derive from MyCommand and that contain additional members depending on the command type. My question is if I call handle() and pass an instance of one of these derived classess, will Ice marshall/unmarshall the entire object or only the members that are part of the Slice definition? In other words, will I be able to cast the object back to it's specialization on the other side and not lose any data?

Hopefully that makes sense.

Thanks,

Nick

Comments

  • benoit
    benoit Rennes, France
    Hi,

    Ice only marshalls the data defined for the Slice class. If you want to instantiate a specialization of the MyCommand class on the other side, you will need to register an Ice::ObjectFactory object with the Ice communicator to create the right instance. See here and here in the Ice manual for more information.

    To transfer the attributes of your specialization, why not declare this specialization in Slice?

    Cheers,
    Benoit.
  • The project I am working on favors the notion of an abstract IPC mechanism; the ability to replace Ice with some homegrown product or corba, etc. without having to modify code outside of the IPC setup.

    I realize that this cannot be fully accomplished since the objects used must descend from classes generated by Slice scripts but I was hoping to minimize the exposure of our programmers to Ice by providing a single Class from which they could derive their objects. Obviously what I am hoping to do defeats the cross-language benefits of Ice, but I wanted to at least explore that possibility anyway. And now I know its not possible so I'll continue on. Thanks :)

    Nick
  • matthew
    matthew NL, Canada
    halfhp wrote: »
    The project I am working on favors the notion of an abstract IPC mechanism; the ability to replace Ice with some homegrown product or corba, etc. without having to modify code outside of the IPC setup.
    ...

    This is, practically speaking, impossible to do, unless your system is trivial, or the IPC systems are you using are clones of one another in all respects (which is never the case). I tried to do a similar thing years ago using systems of identical specification, and it was very difficult (and in the end worthless). Doing so across IPC systems of differing specification would be much more difficult.