Boost logo

Boost :

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


On Dec 7, 2009, at 7:08 PM, Robert Ramey wrote:
> The "real" solution which I envision is just to suppress tracking
> in an archive. [...]
>
> If such facility were implemented, one would proceed
> something like this.
>
> create an output stream. This would not be a file
> stream but rather be plugged into a communication channel.
> If asio doesn't have something like already, I'm sure a
> "channel_buffer" would easily be crafted. Open
> this stream and connect to the other application.
>
> Then open the archive using this ostream as an
> argument. On the other side of the channel open
> an archive using an istream (with this channel_buffer type).
>
> Then your in business !!. The sending side just uses
> the << operator to send any data it want's while
> the other side just uses the >> operator to reconstruct
> any data sent. Easy as pie !
>
> So, to my way of thinking, that's the real solution.

While that is an interesting solution to some problems, I don't
think it actually helps with my use-cases (multiple).

As mentioned earlier, turning off pointer tracking is not an
option for me in some cases. I can envision various ways to deal
with that. If one had a means for determining whether serializing
a data structure used or would use tracking one could use this
approach now, with no [further] changes to the serialization
library.

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.


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