From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-01-08 12:10:46
----- Original Message -----
From: "Philippe Mori" <philippe_mori_at_[hidden]>
> ----- Original Message -----
> From: "christopher diggins" <cdiggins_at_[hidden]>
> 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.
> *** 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
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
Are we on the same page here? And is this something that has some potential
value to boost?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk