Hi, egoots <egoots@gmail.com> 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