Re: [Boost-users] [asio][serialization] read_until end of archive, which delimiter

From: Christian Rössel (christian.roessel_at_[hidden])
Date: 2006-10-20 09:45:41

Robert Ramey schrieb:
> Christian R�ssel wrote:
>> Dear all,
>>
>> I want to receive a boost::archive::text_iarchive using the
>> boost::asio::read_until () function.
>>
>>  boost::asio::streambuf response;
>>  boost::asio::read_until(socket, response, boost::regex("\r\n"));
>>  std::istream responseStream(&response);
>>  boost::archive::text_iarchive responseArchive (responseStream);
>>  responseArchive >> retVal;
>>
>> The data is sent using code linke this:
>>
>>  boost::asio::streambuf response;
>>  std::ostream commandStream (&response);
>>  boost::archive::text_oarchive responseArchive (commandStream);
>>  const ReturnValue retVal (42);
>>  responseArchive << retVal;
>>  boost::asio::write(socket, response);
>>
>> If I use boost::regex("\r\n") or a character that does not occur in
>> the sent archive, read_until throws an eof exception. If I use a
>> delimiter that is contained in the archive, read_until succeeds and
>> the streambuf does contain the entire archive, not only up to the
>> delimiter.
>>
>> What is the correct way to read the entire archive without throwing an
>> exception?
> 
> I think the "correct way is to be sure the archive is destroyed before 
> sending.
> This should append a /n at the end - (at least in 1.34 - this might be a 
> problem
> with previous versions - or maybe not.) So the above would look like:

Appending a '\n' by destroying the archive does not work with boost 1.33.1,
at least in my case.

> boost::asio::streambuf response;
> std::ostream commandStream (&response);
> {
>     boost::archive::text_oarchive responseArchive (commandStream);
>     const ReturnValue retVal (42);
>     responseArchive << retVal;
> } // archive closed appends /n at this point.
> boost::asio::write(socket, response);
> 
> 
> or you could just append a \n to commandStream

This did the job for me. Thanks.

But there is still Christophers question:
> Is there a guarantee that a "\n" delimiter will not occur in the
> middle of the serialised output?

Cheers,
Christian