Boost logo

Boost :

Subject: Re: [boost] Updated performance resultsusing BoostSerialization 1.41
From: Kim Barrett (kab.conundrums_at_[hidden])
Date: 2009-12-09 19:07:40


On Dec 9, 2009, at 3:25 PM, troy d. straszheim wrote:
> Kim Barrett wrote:
>> However, none of my existing use-cases are stream oriented. They
>> are instead all transaction / packet oriented. This means there
>> needs to be a clear boundry, where all output to be generated by
>> the archive has been flushed to the buffer collecting the data,
>> any "end of archive" data needs to be written, and the next
>> transaction / packet needs to include any "beginning of archive"
>> data needs to be written again. Right now I'm accomplishing that
>> by deleting the old archive and creating a new one. I'm looking
>> for either a lighter weight alternative to that (preferably), or
>> a way to make that delete / recreate lighter weight.
>
> How about flush()? I implemented such a thing back in 2005:
>
> http://lists.boost.org/Archives/boost/2005/03/81544.php
>
> I would still find it useful, I have a lot of code that relies on anonymous scopes to control construction/destruction of archives, the code would look a lot more straightforward if I could just flush().
> The use case is can be modeled the same was as sending packets over the network. Each packet needs to have internal pointer tracking, but independent of the others.

This is similar to the "reset" operation that I suggested, also back in 2005. Your flush() operation keeps the class information and only discards object identity information. That doesn't work if some of the receivers might not get every bit of data, as can happen when using an unreliable network protocol such as UDP. That is one of the use-cases of interest to me. There are others that are similarly unreliable, in the sense that receivers will always get complete "packets" of data, but might not get all of them.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk