On Wed, Jan 4, 2012 at 5:21 PM, Chris Cleeland <chris.cleeland@gmail.com> wrote:
On Wed, Jan 4, 2012 at 1:44 PM, Nat Linden <nat@lindenlab.com> wrote:
Let's postulate a new Boost.Iostreams Concept to describe an object capable of buffering data between producer and consumer. Until we can settle on a better name, as a placeholder, let's just call this a Queue.
You could call this thing a "conduit".
Interesting! Although the term doesn't quite jump out at me, I can understand the metaphor, and to my knowledge it has the virtue of not already being hopelessly overloaded. If other people like it, I could go with that.
... I actually need an unbounded Queue for this.
AND
It would also be possible to implement a Queue based on an actual OS pipe.
Beware that OS pipes are bounded.
Yup, I know that. Sorry I wasn't clearer: I intended to suggest three different plausible implementations of the Queue/Conduit concept, with variations on the one I'm actually planning to build. For an unbounded implementation I'm toying with a std::list< std::basic_string<Ch> >. I consider it interesting that you could fairly simply build an implementation around an OS pipe, but that doesn't address the use case that interests me most at the moment. I tossed it out there for purposes of illustration -- I guess a bit too tersely.