By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,131 Members | 1,867 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,131 IT Pros & Developers. It's quick & easy.

Unbuffered basic_streambuf Implementation

P: n/a
Is this even possible? I've found some references to specific "unbuffered"
type methods that exist in older incarnations of basic_streambuf but not in
newer ones.

Info please. :P
Jul 22 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a

<ye**@twenty.net> wrote in message news:EJeYc.54284$S55.26683@clgrps12...
Is this even possible? I've found some references to specific "unbuffered"
type methods that exist in older incarnations of basic_streambuf but not in
newer ones.


It's easy to write a stream buffer which performs unbuffered output. Simply
refrain from using the put-area pointer manipulation function setp, etc., and
override overflow (and possibly xsputn) to write directly to the underlying data
sink.

For input, you need a small buffer to support peeking at the next character
without consuming it and putting back a character that has already been
consumed.

Angelika Langer and Kluas Kreft present an unbuffered streambuf implementation
in their text 'Standard C++ Iostreams and Locales', p. 299. Their implementation
uses a buffer of size 1. I believe I found that this implementation does not
work with STLPort, which routinely peeks at the next character internally so
that the putback buffer is always full. So for 'unbuffered' input I always use a
buffer of size at least 2.

I have written an iostreams library which makes it easy to define new streams
and stream buffers. It's up for review for includion in Boost right now. I
encourage anyone who is interested to participate in the review process on the
Boost developers list (see http://www.boost.org/more/mailing_lists.htm#main).

Jonathan
Jul 22 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.