Hi,
In article <8qafga$k95$1@nnrp1.deja.com>,
  sirwillard@my-deja.com wrote:
> > Although stream can be unbuffered, performance will be much better
if
> > the streams are in fact buffered because an implementation can take
> > advantage of using arrays of character objects, eg. by using
> > 'std::find()' on pointers rather than on
'std::istreambuf_iterator's.
>
> Buffering will not always increase performance.

I'd say it will always increase performance, at least with an
implementation taking full advantage of the buffer and with
reasonably sized buffered (ie. a minimum of say 32 characters).
Basically, an unbuffered stream goes through one condition and one
virtual function just to put or get just one character. Even if the
buffer is copied later, this is less expensive than accepting this
additional cost.

> In the case of
> strstreams and stringstreams buffering won't help.  Why not?  Because
> the "stream" in question is already in memory.

In the case of strstreams and stringstreams the memory used *is* this
buffer! Just have a look at the stream buffer I provided in my
previous article to this thread: This does nothing else than setting
up a buffer to write to a certain area of memory. The resulting stream
is buffered and the implementation can take full advantage of accessing
just an array of characters, rather than individually extracting or
inserting each character.

> Using a buffer here
> will just duplicate the actual buffer.  You are right in saying that
> buffering is specifically catered for in iostreams, since it is often
> the best approach for performance reasons.  However, it's not mandated
> nor even always appropriate or better (maybe not even possible) to do
> so.

I would really like to see an unbuffered stream buffer which could not
improved by adding a buffer - except, of course, if it is not possible.
Basically the situations where it is not possible is where the stream
cannot be buffered due to semantic reasons, eg. to ascertain some kind
of synchronization with a different stream as is the case for the
standard stream objects ('std::cin', 'std::cout', etc.) in the default
setting: This is why these stream might be rather slow. However, all
reasonable implementation try to use a buffer in one way or another
even for those stream, typically at the cost of depending on a certain
implementation of the stdio files.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8qapvu$11d$1@nnrp1.deja.com>,
  Dietmar Kuehl <dietmar_kuehl@yahoo.com> wrote:
> Hi,
> In article <8qafga$k95$1@nnrp1.deja.com>,
>   sirwillard@my-deja.com wrote:
> > > Although stream can be unbuffered, performance will be much better
> if
> > > the streams are in fact buffered because an implementation can
take
> > > advantage of using arrays of character objects, eg. by using
> > > 'std::find()' on pointers rather than on
> 'std::istreambuf_iterator's.
> >
> > Buffering will not always increase performance.
>
> I'd say it will always increase performance, at least with an
> implementation taking full advantage of the buffer and with
> reasonably sized buffered (ie. a minimum of say 32 characters).
> Basically, an unbuffered stream goes through one condition and one
> virtual function just to put or get just one character. Even if the
> buffer is copied later, this is less expensive than accepting this
> additional cost.
>
> > In the case of
> > strstreams and stringstreams buffering won't help.  Why not?
Because
> > the "stream" in question is already in memory.
>
> In the case of strstreams and stringstreams the memory used *is* this
> buffer! Just have a look at the stream buffer I provided in my
> previous article to this thread: This does nothing else than setting
> up a buffer to write to a certain area of memory. The resulting stream
> is buffered and the implementation can take full advantage of
accessing
> just an array of characters, rather than individually extracting or
> inserting each character.

We're using different words but speaking of the same thing.  A seperate
buffer is not needed, and using a seperate buffer will add overhead and
decrease performance.  When I use the term "buffer" here I mean a
seperate chunk of memory used to buffer I/O between reads/writes to the
physical device.

> > Using a buffer here
> > will just duplicate the actual buffer.  You are right in saying that
> > buffering is specifically catered for in iostreams, since it is
often
> > the best approach for performance reasons.  However, it's not
mandated
> > nor even always appropriate or better (maybe not even possible) to
do
> > so.
>
> I would really like to see an unbuffered stream buffer which could not
> improved by adding a buffer - except, of course, if it is not
possible.

The not possible part is the biggy, though streams for devices that
already have a "buffer" that can be directly addressable, such as the
stringstreams and strstreams above, are also not candidates for
additional buffering (again, by this I mean using an additional memory
buffer).

> Basically the situations where it is not possible is where the stream
> cannot be buffered due to semantic reasons, eg. to ascertain some kind
> of synchronization with a different stream as is the case for the
> standard stream objects ('std::cin', 'std::cout', etc.) in the default
> setting: This is why these stream might be rather slow. However, all
> reasonable implementation try to use a buffer in one way or another
> even for those stream, typically at the cost of depending on a certain
> implementation of the stdio files.

Agreed.  In general buffering is a good thing and most stream
implementations will strive to buffer the data.  The original OP seemed
to think that buffering was required or was at least the compelling
reason to have iostreams so that having an iostream with out buffering
made no sense.  I've just been pointing out that this isn't so.

--
William E. Kempf
Software Engineer, MS Windows Programmer


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Why do the strstream classes exist? Why do you need buffering since you
are writing to a memory buffer?

regards,
Kurt Krueckeberg


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8q8g5k$bt2$1@nnrp1.deja.com>,
  kkruecke@my-deja.com wrote:
> Why do the strstream classes exist? Why do you need buffering since
you
> are writing to a memory buffer?

strstream exists for backwards compatibility ;).

stringstream exists so that you can create formatted strings using the
same interface as you would for any other iostream.  This is the only
way to get formatted output of UDT and the only way to get formatted
output of built in types in a typesafe manner.

Buffering isn't really an integral part of iostreams.  In fact, an
iostream may not buffer at all, as is clearly evidenced by the
requirements of the basic_streambuf in the standard.

--
William E. Kempf
Software Engineer, MS Windows Programmer


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,
In article <8q8odi$m1u$1@nnrp1.deja.com>,
  sirwillard@my-deja.com wrote:
> In article <8q8g5k$bt2$1@nnrp1.deja.com>,
>   kkruecke@my-deja.com wrote:
> > Why do the strstream classes exist? Why do you need buffering
> > since you are writing to a memory buffer?
>
> strstream exists for backwards compatibility ;).

Actually, the strstream family provides the facility to tie a chunk of
memory to a stream which is not available eg. using the stringstream
family. However, it is not hard to create this part of functionality
either:

  struct membuf: public std::streambuf {
    membuf(char* memory, std::streamsize size) {
      setp(memory, memory + size);
      setg(memory, memory, memory + size);
    }
  };

But then, the strstream family provides support for seeking, too, which
is missing from the above stream and which is somewhat nasty to create.

> Buffering isn't really an integral part of iostreams.  In fact, an
> iostream may not buffer at all, as is clearly evidenced by the
> requirements of the basic_streambuf in the standard.

Although stream can be unbuffered, performance will be much better if
the streams are in fact buffered because an implementation can take
advantage of using arrays of character objects, eg. by using
'std::find()' on pointers rather than on 'std::istreambuf_iterator's.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8q8r63$pip$1@nnrp1.deja.com>,
  Dietmar Kuehl <dietmar_kuehl@yahoo.com> wrote:
> Hi,
> In article <8q8odi$m1u$1@nnrp1.deja.com>,
>   sirwillard@my-deja.com wrote:
> > In article <8q8g5k$bt2$1@nnrp1.deja.com>,
> >   kkruecke@my-deja.com wrote:
> > > Why do the strstream classes exist? Why do you need buffering
> > > since you are writing to a memory buffer?
> >
> > strstream exists for backwards compatibility ;).
>
> Actually, the strstream family provides the facility to tie a chunk of
> memory to a stream which is not available eg. using the stringstream
> family.

Sorry, I was attempting to be humorous here.  I realize there are valid
uses for this class beyond backwards compatibility.  However, bacwards
compatibility must have been the major driving force for this class.  I
wasn't part of the standardizations board, so I'm deducing here, but
the deduction is based on strong evidence.  For example, strstream and
related classes are part of "Appendix D (Normative) Compatibility
Features" in the standard.  Further, if the driving force were to allow
the facility "to tie a chunk of memory to a stream" than they would
have likely templatized the class to allow for any char type, the same
as was done for other iostreams.  After all, it's just as valid to
format a wchar_t stream in a chunk of known memory as it is for a char
stream.

> > Buffering isn't really an integral part of iostreams.  In fact, an
> > iostream may not buffer at all, as is clearly evidenced by the
> > requirements of the basic_streambuf in the standard.
>
> Although stream can be unbuffered, performance will be much better if
> the streams are in fact buffered because an implementation can take
> advantage of using arrays of character objects, eg. by using
> 'std::find()' on pointers rather than on 'std::istreambuf_iterator's.

Buffering will not always increase performance.  In the case of
strstreams and stringstreams buffering won't help.  Why not?  Because
the "stream" in question is already in memory.  Using a buffer here
will just duplicate the actual buffer.  You are right in saying that
buffering is specifically catered for in iostreams, since it is often
the best approach for performance reasons.  However, it's not mandated
nor even always appropriate or better (maybe not even possible) to do
so.

--
William E. Kempf
Software Engineer, MS Windows Programmer


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]