[boost] Re: [ANN] Format Lite

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-11-12 16:21:14

"Robert Ramey" <ramey_at_[hidden]> wrote in message
news:cn36dn$j1i$1_at_sea.gmane.org...
>
> "Jonathan Turkanis" <technews_at_[hidden]> 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