Hi!

Is basic_ostream [or children] allowed to buffer data internally apart
from its streambuffer (except _inside_ its methods). Well it doesn't
make sense to me, but is there any assurance in the ISO standard that
after a return of any ostream method the streambuffer is up to date ?


Another one: is there any promise, that one call to any output method of
an ostream will result in at the most _one_ call to an output method of
streambuf ? I'm afraid no [27.6.2.1 (2) "Both groups of output functions
generate (or insert) output characters by actions equivalent to calling
rdbuf().sputc(int_type)"] but it would come handy right now for me!  :)

Roman

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

pi-314@web.de (Roman Krenick   ) wrote in message news:<40B3B8E2.70309@web.de>...
> Hi!
>
> Is basic_ostream [or children] allowed to buffer data internally apart
> from its streambuffer (except _inside_ its methods). Well it doesn't
> make sense to me, but is there any assurance in the ISO standard that
> after a return of any ostream method the streambuffer is up to date ?

I don't know of any text that goes as far as to say so explicitly but
I think it's implied by [lib.ostream], p1 through 3. The descriptions
of the individual member functions are also pretty tight (e.g. the
arithmetic inserters) so any buffering is, IMO, out of the question.

>
>
> Another one: is there any promise, that one call to any output method of
> an ostream will result in at the most _one_ call to an output method of
> streambuf ? I'm afraid no [27.6.2.1 (2) "Both groups of output functions
> generate (or insert) output characters by actions equivalent to calling
> rdbuf().sputc(int_type)"] but it would come handy right now for me!  :)

Nope. Think of operator<<(int) for instance: it writes into the buffer
through ostreambuf_iterator (via the num_put facet) one character at a
time by calling sputc().

Note also that [lib.ostream], p2 of C++ 98 even prohibits
implementations from calling any virtual streambuf members other than
overflow(), requiring even opertator<<(char*) to call sputc() for
every character. I believe C++ 03 fixed this by allowing calls to
xsputn().

Martin

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Martin Sebor wrote:
 >
> Note also that [lib.ostream], p2 of C++ 98 even prohibits
> implementations from calling any virtual streambuf members other than
> overflow(), requiring even opertator<<(char*) to call sputc() for
> every character. I believe C++ 03 fixed this by allowing calls to
> xsputn().
>

Unfortunately, this issue has WP status, that means it's not included in
TC1, but will probably be included in future versions of C++:

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#165

BTW, the three library implementations I have access to use sputn()
(that eventually invokes xsputn()) to implement operator<<(char*). The
right thing, IMHO ;-)

Alberto

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]