Re: [boost] Serialization and disctintion between eof and end of archive

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-01-30 12:05:53

Maciej Sobczak wrote:
> Hi,
>
> The boost.serialization library seems to use eod-of-stream in the
> underlying istream object to denote the end-of-archive.

Why does it seem that way? It would certainly be contray to my
intention.

> This equivalence might make sense with files where the stream is open
> for a short time and really associated with a single archive,

> but seems to be cumbersome when used with streams that are supposed to be
> long-lived (network sessions?) and used for transmission of many
> separate archives.

I don't see that this would be a problem.  What is the matter with
the following?

?ostream os("pipename or whatever");

// first archive
{
    ?_oarchive oa(os);
    oa << ...;
} // archive is destroyed here - stream remains open and available
// second archive
{
    ?_oarchive oa(os);
    oa << ...;
} // archive is destroyed here - stream remains open and available

os.close();

>
> The problem arises between two applications that want to use
> serializatioin library for data exchange "on the fly", using network
> sockets. Small tests have shown that it's not enough for the sender to
> flush its output streams (although it does result in the archive's
> data arriving at the destination side). For the archive to be read
> correctly, the sender needs to entirely close the connection. This
> indicates that the end-of-stream condition is used to denote
> end-of-archive in the serialization sense.

I don't believe the conclusion follows.  The archive has to be
constructed and destroyed - but the stream doesn't have to be.

> Taking into account the interface of the serialization library (where
> the readers are created from streams), where the stream object is
> syntactically supposed to live longer than the archive, treating eof
> as eoa is counterintuitive.
> I really expect this to work for the receiver:
>
> std::istream &is = ...; // some input stream, possibly long-lived
>
> while (...)
> {
>     boost::archive::text_iarchive ar(is);
>     // ...
> }
>
> with similar structure on the sender-side.
>
> Any thoughts?

I also expect this to work

Robert Ramey