----- Original Message ----- From: "Philippe Mori" <philippe_mori@hotmail.com>
----- Original Message ----- From: "christopher diggins" <cdiggins@videotron.ca>
As some has point out, I think that it should not be necessary to derive from a class with a virtual function. Unnecessary coupling.
I can live with that. [snip]
*** Well, I think this should give an idea of a possible design.
Thank you for the suggestions and taking the time to look over the code.
In fact, we might need a temporary object so that we would be able to write to the final stream but we can also do it in the destructor (although this might cause problem wwith exception safety if an error occurs while writing to destination.
Oh, this is how I implemented it in my code. I forgot about the dangers of writing code in destructors.
A simple solution would be to have an object that would indicate to flush to the destination. This would even allows to write to the target in part if after writing and flushing the stream we leave it open (and the input stream would be kept at the current position).
An exemple:
Mgr(params) | Fn1 | Fn2 | Fn3 | Flush | Fn4 | Fn5 | Flush.
This would be similar to the uses of ends for STL stream but eventually with the possibility of having more than one.
This is an interesting idea. In order for control (i.e. partial reading and partial writing) to switch back and forth between Functions, it would however require the use of threads. This counters my original design intent, but I am not against doing a separate mini-library which is more appropriate for boost. I think it would be appropriate, if I go in this direction to then use the boost::iostreams library, and write a function to a threaded iostream-filter converter. Then perhaps I could simply overload the pipe operator (|) for iostreams filters? Are we on the same page here? And is this something that has some potential value to boost? Christopher Diggins http://www.cdiggins.com