Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-11-18 15:42:59

I have several serious issues with the library, based on five hours of
study of the documentation, headers, and sample code:

* tutorial.html - The examples led me think that it isn't easily possible
to serialize a given class in more than one way (with more that one
save/load descriptor). An example of how to do this would be appreciated,
such as serializing only on degrees and minutes (ignoring seconds).

* The lack of alternate archive formats is a showstopper, IMO. I would
expect to see text, CSV, XDR, platform specific binary, HTML, and XML
either supported or at least discussed or given as example code. That is
the only way to make sure that the hooks are present. If that seems like a
long list, remember that doing proof-of-concept for those formats with
Jens' library was not at all difficult. (Note that I don't personally have
a need for all formats to support all C++ data structures. If a CSV (comma
delimited) format doesn't support full pointer functionality, for example,
that's fine with me.)

* I'm concerned that the library is so aimed at solving difficult problems
(pointer issues, for example) that the simple use cases aren't being given
enough consideration. Can't tell if this is just my misunderstanding, the
docs need work, or there is a serious underlying problem. Perhaps layering
like Boost.Test, or separation of orthogonal parts as described by Yitzhak
and Vladimir is needed. I'll volunteer to contribute some use cases that
concern me.

Less serious issues:

* Please use regular Boost directory structure sub-directories:

* overview.html/Requirements (7) "File portability - files created on one
platform should be readable on any other." It is a requirement that
portability be possible, but all formats are not required to be portable.
Binary formats in particular should be free to choose platform dependent

I'd also add:

10. Orthogonal specification of external (I/O) formats, including the
ability to reorder or filter class members, and the ability to have
multiple serialization formats for an object.

11. Reasonably easy to cope with common formats like comma separated value
(CSV) that are created or consumed by a text editor or a DBMS or a non-file

Presumably (11) is a side effect of meeting (10), but expressing it
explicityly may help to alert people to the idea that the end consumer or
provider for serialization data may be something other than the
serialization library itself.

* rationale.html "Saved objects must be const." I understand the need that
objects not change during a save or load, but surely you can't mean the
objects are actually const themselves? The reference confused me even more
regarding constness, where you say not to create constness via a cast.
Maybe an example would clarify what you mean here.

* rationale.html - I was expecting to see rationale for why Jens'
"describe" technique wasn't used. It seems so much more elegant and far
less error prone than writing separate save and load lists, so there should
be a strong rationale for not using it.

* tutorial.html - First sample program -

void main() {
     // create and open a character archive for output
     ofstream ofs("filename", ios::binary);
     boost::oarchive oa(ofs);

     // create class instance
     const gps_position g(35, 59, 24.567f);
     // write class instance to archive
     oa << g;
     // close archive

Shouldn't that be ofs.close()?

It would be helpful to show the output of the that first example.

Based on the above serious issues, I vote no as the library now stands.
A lot of thought and work has gone into the serialization library.  I hope 
that Robert will continue his work on it, and clear enough issues that it 
can become part of Boost.
I also hope that those of us who have complained about aspects of the 
library will be willing to work with Robert to resolve the issues.

Boost list run by bdawes at, gregod at, cpdaniel at, john at