[boost] RE: Serialization Library Review

From: Robert Ramey (ramey_at_[hidden])
Date: 2002-11-17 01:50:23

From: "Jeff Garland" <jeff_at_[hidden]>

>From my perspective the following changes must are must-haves:
>1) The library must have a 'real' test suite that checks.  We will never get this
>   ported without some automated tests. Further, it is simply too much to ask users
>   to use this library without some tests that show that it works on their
>   platform/compiler.

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.

>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

>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?

>4) Jamfiles that build a library using the boost standard directory form.  It took me a
>   good 30 minutes to realize that my linking error was a result of a failure link
>   the archive.o, serialization.o, and void_cast.o.  The combination of so many
>   header libraries in boost and the lack of directory definition in under /lib
>   put me in the wrong mindset.

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.

>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

>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.

>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?

I'm flabbergasted at the output from gcc 3.2 as well as the fact that it doesn't seem
to permit derived virtual functions to be private if the ones in the base class are public.

As I said I'm getting clean compiles from mingw(gcc 2.95), msvc7, and comeau(almost)
so you might want to do some sort of checking

Robert Ramey