#132: Virtual Serialization: Spare need for self-class type macro arguments

[PhilMiller]

No description provided.

[PhilMiller]

Handling for the PARENT class of derived classes will require a different kind of cleverness. I think one possible line of attack would be to take advantage of the fact that during execution of a derived class constructor, its vtable pointer is set to that of its parent class. We could maybe use a hidden member variable inside the derived class declaration macro whose own constructor could do something clever with querying the registry.

[lifflander]

This looks good to me. We could do this in two steps starting with this to remove one of the parameters. We will need to time this with an update to EMPIRE when we merge this.

[PhilMiller]

Both modified macros are under new names, with the old names that take the existing arguments kept for backwards compatibility. So, we can merge into EMPIRE whenever, update it at leisure, and then drop out the old ones.

[PhilMiller]

Also, I went looking and saw that until vt#1013, nothing there uses the virtual serialization machinery at all.

[PhilMiller]

So, if we adopt this sooner rather than later, footprinting code can just use the new form from day one.

Anyway, given you're happy with this, I'll do the clean-up on formatting and whatnot, and we can merge this.