RE: [boost] RE: Serialization Library Review

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-11-17 11:01:38

> The program test.cpp tests every aspect of the library that I can think of. I have included
> all the tests in one program because it is convenient to for me to develop with.

Ok.  It may be sufficient once it compiles :-(  Sorry I didn't actually look 
at it until now.  At the very least a section in the documentation discussing 
the existence of this would be helpful.
 
> >2) I'm concerned that gcc 3.2 won't compile the 'tests' out of the box (see below)
> 
> I havn't been able to get gcc 3.2 working on my machine

You mean the compiler or library?

> >3) While the demo is the 'big' complete example, there needs to be a 10 synopsis
> >   example using standard types.  Programmers understand code faster than prose.
> 
> ? 10 synopsis example?

What I was trying to say was a 10 (ok maybe 50 line) example program that one can
'understand at a glance'.  Something like what I attached on my first message.
 
> I have never been able to build the boost libraries on my system. The Jam build
> never worked for me.  I just gave up on it since it turned out that I only used boost
> header code anyway.  For testing, its just easier to create a library.

I understand your issue completely.  I went thru the same learning curve.
What platform and issues?  I'm sure we can help get you over the issues.
 
> >5) Having to hack changes (make operator<<'s public) into archive.hpp for a simple
> >   program to archive shouldn't be required.  I wasn't sure if this was a design
> >  flaw or the intent.
> 
> Never saw that on any other compiler, I've been using MSVC7, mingw and comeau

Did you try my little example code?  Maybe there is something different because
I'm not declaring any types a friends to serialization?
 
> >Requiring a default constructor is a mistake. 
> 
> A default constructor is not required.  The reference section "Serialization Overrides" explains
> this and gives a code excerpt showing what one has to do to use a constructor with arguments.

Ah, thanks I missed that...

> >Why not derive a different exception from archive_exception for each of the
> >enum types instead of using the enum?  This would be better because if a user
> >creates a new archive type they might need to add an exception type which is
> >not currently possible.
> 
> Wouldn't it be better for the user to derive his own exception from archive_exception?

Right, my point is that you should too.  More than likely most client code will
catch on std::exception, but I can easily imagine wanting to do some different
behavior for say "unsupported version" versus "pointer conflict".  So now I 
have to write client code that looks like:
   try {
       // serialization code
   }
   catch(xtended_archive_exception& xe) {
       // do something here...
   }
   catch(archive_exception& ae) {
        switch(ae.code){
        case unsupported_version: { //do something }
        case pointer_conflict:    { //do something else}
        default: { //do yet something else}
      }
   }

Very uneven compared to:

   try {
       // serialization code
   }
   catch(xtended_archive_exception& xe) {
       // do something here...
   }
   catch(invalid_version_exception& ive) {
       // do something else here...
   }
   catch(archive_exception& ae) {
       // do the default...
   }

Jeff