Re: [Boost-users] [serialization]

David Abrahams wrote:

Paul Giaccone writes:

...

Robert Ramey wrote:

...

Let it be known that:

For anyone with the hope that the serialization library can prevent you

from creating an erroneas archive - these are false hopes.

...

Right, so could you make this known in the documentation, along with dicussion of the cases when this can occur, in order to help users with use of the library and debugging of their code, please?

Suppose I write a File class. Do I need to say explicitly that if you write random bites into the middle of a File instance that the class can't protect you from corrupting your filesystem?

That's the same sort of thing as passing uninitialized data when an interface isn't documented as accepting raw storage; it's always wrong. No component that expects a reference to T should ever have to document that the T must be initialized. IMO, that would be silly.

No, of course there is no need to say this. The typical programmer is familiar with the concept of GIGO. If you don't initialise your data, you can't expect your program to work, simple as that. Saying "Don't forget to initialize your data before you write it to the archive, guys!" would be silly, as you say. However, this is not what I am requesting. What I am asking for is a note in the documentation on the page headed "Serialization - Archive Exceptions" under "stream_error" that says something along the lines of "This exception can also occur when reading an archive to which uninitialized data has been written. I/O of uninitialized data is undefined." The idea is not to treat programmers with kid gloves by reminding them to make sure they remember to initialise their variables, but rather to point out to the user another reason why a stream_error might occur (note I say "might", because it seems that there are cases in which uninitialised data written to an archive can in fact be read back in harmlessly, even though this is deprecated) and so assist them with debugging their code. I don't see it as telling users what they should know already; it's simply listing another situation (along with not having a terminating new line or not destroying an output archive on a stream before opening an input one on the same stream) that can cause a stream_error exception to be thrown. Here's why I think this is important. Before using the library, I had written my own serialisation code, and everything seemed to be working fine, even though I had uninitialised variables in my code that I was unaware of at the time. Then I used the serialization library and got this error. This suggested to me that either there was something wrong with the way I was using the library or there might be a bug in the library, rather than suggesting a bug in my code. Looking through the documentation, the way I was using the library seemed to be fine, so I started this thread (which seems to be chasing its own tail rather than coming to any practical conclusions). A note to the effect I am proposing would have enabled me to find the problem much more quickly, and would no doubt assist other puzzled users too. Thanks, Paul