Saving class hierarchies is trivial. For a list of the base class, just call the virtual method Save() or whatever, and it''ll know what to write out to the file. But when I want to load in a list of the base class... it gets awkward. Since I don''t know the type of the class prior to loading it in, I am not able to allocate enough memory for it. So I would need to load in some sort of identifier as to which class it is, instantiate it, and then call its own Load() function directly. But this requires that I know all the possible base classes beforehand (in order to pair an identifier to a typename), which just instinctively seems ''wrong'' to me: after all, most of the time you should be able to just drop in a derived class and the virtual interface in the base class should cover the details. One of the benefits of OO programming is that you can add in new code without altering old code, but I don''t see how to do it well in this example. Anyone have any ideas?

Hmmm, that''s an interesting problem.

You''d have a virtual function "Load" in your ( possibly abstract? ) base class. You could store an identifier in the base class to know what the derived class of it is, but then the base class would have to know all of its derived classes, which is what you''re trying to avoid, right?

*thinks about it* I think you can''t solve that elegantly within the class architecture. It requires knowing what you are loading before you load it .

You COULD write a separate "loader" class, that does know all of the derived classes, and let the delegation happen in there, but that''s just a hack, not really a solution;

#pragma DWIM // Do What I Mean!
~ Mad Keith ~
**I use Software Mode**

Kylotan: The easy way would be the method that MFC chose, which is to use macros to place a static CreateObject() function in each class. That function creates a new object of the type and returns a pointer to it. More information can be found by searching the MFC source and headers for #define DECLARE_DYNCREATE and #define IMPLEMENT_DYNCREATE.

(Interestingly enough, that's the language feature I listed in the Exceptions... post. I think RTTI should be able to create objects from a stored type_info class, but perhaps that would involve too much overhead.)


- null_pointer
Sabre Multimedia


Edited by - null_pointer on 5/4/00 6:03:47 PM

Check out Mason''s article "Pluggable Factories Rock My Multi-player World" (or something like that) article. He discusses how to instantiate message classes from just an ID, and it sounds like you''re trying to do the same thing.

I use a very similar approach, but I like his better. Mine requires registering the known class types at startup, but the way his article describes how to do it, it''s all done for you after the initial setup. Really cool stuff.

Mark Fassett
Laughing Dragon Entertainment
http://www.laughing-dragon.com

I do belive this is called COM/DCOM/COM+ on the Win platform