Boost logo

Boost :

From: Matthias Troyer (troyer_at_[hidden])
Date: 2002-02-11 07:31:44


On Monday, February 11, 2002, at 10:31 AM, quendezus wrote:

> --- In boost_at_y..., Matthias Troyer <troyer_at_i...> wrote:
>> Maybe I miss the point but I don't see how this will work. In
>>
>> you explicitly write the stream type (binary_stream) in the
>> (de)serialization functions for the class A. Thus as far as I
>> can see, you only use one type of stream ever.
>>
>
> I think "how to write in the stream buffer" should be a user
> decision. In the 3 examples I have posted, the framework (the
> persistence library) only calls :
> std::streambuf& operator<<( std::streambuf& dest, const A& a );
> std::streambuf& operator>>( std::streambuf& src, const A& a );
> Then the user decides what do do with the streambuf, usually wrapping
> it into a stream class.

No, in my use the library decides into which kind of stream to write:

i) for checkpointing into a file (e.g. in XDR format)
ii) for transferring an object to another node on a parallel machine
     into a message
iii) for viewing with some analysis tool or graphics package in
      HDF format

All three usage scenarions of serializing the object can occur
for the one and the same object in one program. Yes, it is ultimately
the user who decides the format, but at a higher level of the code
than the (de)serialization function of the class.

> See the code below. Does it meet your need?
>
> Sylvain
>
>
>
>
> //-----------------------------
>
> struct A
> {
> int I;
> };
>
> DECLARE_SERIAL( A );
>
> //-----------------------------
>
> // Simple switch debug/release
>
> std::streambuf& operator<<( std::streambuf& dest, const A& a )
> {
> #ifdef NDEBUG
> binary_stream s( &dest );
> #else
> debug_stream s( &dest );
> #endif
> s << a.I;
> return dest;
> }

No, I need at least three different types of streams at runtime.
That's why I think I need some type of polymorphism (templates or
virtual functions) on the stream.

Matthias


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