Re: [Boost-users] wrapping stdlib fstream with boost filtering streams

From: Daniel Oberhoff (daniel_at_[hidden])
Date: 2007-07-10 04:31:30

Hi,

egoots <egoots_at_[hidden]> writes:

 >> 1) does the compressor flush the zlib compression buffer when I  
flush/
 >> pop it?
 >
 > As I understand it, pop() and reset() both flush and close the  
current
 > device and then destroy it.

Well, but I explicitly switched the auto_close feature off...

 >> 2) is fstream a bidirectional stream (my guess due to separate  
seekg/
 >> seekp methods) or a seekable stream (one read/write head)? Because I
 >> currently require the former.
 >>
 >> btw: the above code runs without exceptions, but when I read back
 >> variables I have just written they are garbled.
 >
 > You should read the thread of messages at... there may be some  
relevant
 > info here:
 > http://thread.gmane.org/gmane.comp.lib.boost.user/13824
 >
 > Especially the replies by Jonathan Turkanis

Well, there he says that strict_sync is there to switch filters, but it
wouldn't make sense to use it before all the data is compressed. but
that is exactly the point: all the data IS compressed. Matlab files
effectively consist of carefully concatenated compressed and
uncompressed files. Effectively I could take out a compressed block from
a matlab file and send it to gunzip.

Also, in my code strict_sync returns true, unlike what the original
poster in the mentioned thread has experienced, indicating that all  
has been
flushed and written and switching filters is ok.

I also check after every pop() if the fstream has been closed, and it
has not. Using a different z stream wrapper (zipstream) works (mostly)
and gives me the original data, while the boost approach gives me zeros.

Well, I will try to make a simpler test case, since the program is quite
complex.

thanks 4 the reply

Daniel