[boost] Re: [serialization][test] Helping end-user testingserialisation

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-05-22 22:37:33

I think the problem addressed by the original post is not addressable by
concept checking.

It really address the problem where by one can make a mistake in getting
save and load out of sync.  This can occur in more complicated situatons
where serialize has to be split in to load and save and there are things
like versioning involved.  I'm not sure this idea would be that much help.
I would love an automatic test generation program and indeed many of the
test programs are similar.  The problem I have is that generating the test
data is problematic and in general can't be done automatically.  So at this
point, I would expect that incorporating this idea would be more trouble
that the benefit rendered.

Also, take note of the xml_archive.hpp as it regards testing serialization.
I personally have no use for the xml archive.  Well, now that I have it I do
use it.  It has a couple of valuable attributes.

a) Its readable and so all the extra data in a serialized data file is
labled, eg class id, object reference, name of the data field, etc.
b) On loading, the <name> ... </name> tags are checked to see that they
match.  In fact, if the save and load are out of sync, the load will most
likely trap with an exception at the point where the mismatch exists.

So if you're looking for a problem in your serialization specifications, use
an xml_archive in your test!  Do this even if - or especially if - you're
not otherwise using XML.

As for concept checking.  I'm very interested in this.  When I started the
serialization library, I didn't really understand enough of C++ templates to
appreciate this.  I really didn't know about how to document a library based
on overloading. etc.  I looked at the Concept Checking Library and without
knowing these other things it wasn't really clear how to use it.

Now,  after much more experience with C++, templates etc.  I see how useful
this could be.  To get maximum utility from it, one really needs to make the
documentation in a more formal way.  Based on the informaton on the SGI
website. I've been making small steps in this direction but its a way to go.

If I knew when I started what I know now.  Things would have been different.

a) I probrably would have started the same.  Experimenting with limited set
of simple use cases.
b) When I thought I was ready to deliver something I would make a tutorial.
That would be the same.
c) I would have made a more formal reference document and included Concept
Checking in the code.  From then on these could be kept in sync. (more or
less).
d) I would try to make the test cases to double check the concept checking

I don't think this would have been all that much more work (if any) than the
more ad hoc way I went about it.

But- a major part of getting a boost library working is making it function
on a wide variety of compilers.  Some compilers already scream under the
strain of compiling the serialization library.  I wonder how concept
checking would affect this.

I was at the book store the other day in the computer section, and was
struck by the wide array of titles and the lack of selection.  In short, I
think the world needs a new C++ book.  "How to write a fast, correct,
program in C++" which would presume a working knowledge of C++.  Topics

1) Why templates matter
2) Hto write formal specifications for templates
3) Concept checking
4) Program testing

This might be part of another book "Leveraged Software Development using
Boost Libraries"

1) Simple Application 1 - how boost libraries make it trivial
2) Applicaiton 2 - how ....
3) Using templates and boost to implement an application architecture - case
study Model View Contoller.

Anyway its fun to speculate.

Robert Ramey

David Abrahams wrote:
> Loïc Joly <loic.actarus.joly_at_[hidden]> writes:
>
>> Do you think it would make a worthy addition ?
>
> How about adding concept checking to Boost.Serialization?  The Boost
> Concept Checking library is awesome for finding problems like that.