"Robert Ramey" <ramey@rrsd.com> wrote in message news:cn36dn$j1i$1@sea.gmane.org...
"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message
If the archives are to have additional member functions, as Pavel suggested, it would probably be good to codify them with a new archive concept.
I understand Pavel's proposals to be more specialized serialiizations. This can be either more specialized member templates or more specialized free templates. The idea that an archive is totally independent of the types it serializes would remain intact. What would happen is that now the serialization of a selected classes would be dependent upon the type of archive used.
If we wanted a special type of archive, we could derive from an existing one just to get a new type which can be used to specialize the templated serialze function
Okay.
It would look something like this:
struct Duck; struct Gooose;
struct DuckStuffedWithPork : single_class_formatter<Duck> { template<typename StyledOstream> void operator()(StyledOstream& out, const Duck& d) { /**/ } };
struct BlackenedGoose : single_class_formatter<Goose> { template<typename StyledOstream> void operator()(StyledOstream& out, const Goose& d) { /**/ } };
struct cajun_style : style< use<Duck, DuckStuffedWithPork>, use<Goose, BlackenedGoose> > { };
styled_ostream<cajun_style> cajun_out(cout);
I don't really understand the above example
The point is that you can define several formatters for Duck and several for Goose, and then combine them freely.
but here is what I think you want to do using free serialization functions.
// default serialization template<class Archive> void serialize(Archive &ar, Duck &d){ ar & d; }
// serialization cajun style template<> void serialize(cajun_style_oarchive &ar, Duck &d){ ar & punctuation("&*^#@#@&" & d; }
// define a type for cajun style archives// this is just a named wrapper for text archives. class cajun_style_archive : public text_archive {};
// serialize normal style Duck d; text_oarchive tar; tar << d;
// serialize cajun style cajun_style_oarchive car; car << d;
That would be about it.
The problem comes here (quoting from the above): void serialize(cajun_style_oarchive &ar, Duck &d){ <snip> } I don't want the way Duck is formatted by a cajun_style_oarchive to involve cajun_style_oarchive at all. It should involve just a Duck formatter which can be combined with other formatters to form any number of styled archives. For example, struct style1 : style< use<Duck, DuckStuffedWithPork>, use<Goose, BlackenedGoose> > { }; struct style2 : style< use<Duck, DuckStuffedWithPork>, use<Goose, DeepFriedGoose> > { }; struct style3 : style< use<Duck, DuckStuffedWithPork>, use<Goose, SteamedGooseWithWalnuts> > { }; Here the code for DuckStuffedWithPork needs to be written just once. I wouldn't want to have to write separate specializations class style1_oarchive : public text_archive { }; class style2_oarchive : public text_archive { }; class style3_oarchive : public text_archive { }; template<> void serialize(style1_oarchive &ar, Duck &d){ // .. } template<> void serialize(style2_oarchive &ar, Duck &d){ // .. } template<> void serialize(style3_oarchive &ar, Duck &d){ // .. } Here I have to repeat the commented-out code three times. If you want to vary styles for two or more types independently this leads to a combinatorial explosion.
Of course you're serialize template specialization could be as elaborat as you which to accomodate some program drivien customization. Notice that none of requires alteration of either the classes to be serialized or the archives used.
Regarding pointers, would you agree that most of the thorniest issues relating to pointers disappear if you concern yourself with output only, since you wouldn't have to detect or record the fully derived type or have a mechanism for constructing new objects?
Hmm - maybe - about 5 seconds reflection raise questions like - what about pointers to abstract base classes. Should they serialized the named class, or the most derived class. Should the library use be permited to choose? If so how would he do this. What about systems that don't support RTTI?
I think these are bigger problems for serialization than for formatting. My feeling is that formatting pointers according to their static type would be sufficient for a formatting library, even for abstract base classes, since you don't need to be able to recover the lost information. A user can always supply a formatter for the abstract base class which does exactly what she wants.
If you want to avoid an infinite loops if a cycle occurs, then you'll automatically have multiple detection. Will some user ask for a method to inhibit/enable this?
Yes, I understand that cycle detection remains an issue. The hard part would seem to be implementing cycle detection; providing a switch to turn it off seems simple. I guess your point is that the serialization library has already made these choices. I'm really interested to see what all the issues are.
As I've said before, its not really a technical issue. Its a question of what happens when supplies an elegant solution to part of a hard problem. Depending on the problem domain, that may be just fine. With serialization its exceedingly annoying to start using the system and start to depend upon it only to find that there's an area where you can't use it. Then you're faced with making some sort of kludge to get around it. and the whole appeal of having a "definitive" solution goes out the windows and users howl.
Its a slippery slope. Once you start its hard to stop until you get to the end.
I think a good way to proceed would be to write a quick sample implementation, using ostream wrappers, ignoring some of the messy issues such as formatting pointers. Then I can ask you if it is possible to imitate the behavior using the serialization infrastructure. This will be at least a few months away, however.
Robert Ramey
Jonathan