Martin Bonner wrote:
kanze wrote:
Whether a user defined streambuf should use it [ios::binary]
or not depends on what it does, but I suspect that cases
where it should are very rare.
Agreed.
All it does is control the mapping between the file
representation and the memory representation of end of file and
end of line. There is already a streambuf class concerned with
reading and writing system files: basic_filebuf, and I can't
really think of a case where you would want another one.
Surely whenever the streambuf needs to map between an internal
format, and an external binary format?
You mean between the internal text format (stream of characters,
with end of line indicated by the character '\n') and an
external text format. The role of the binary flag is to turn
off a "default" mapping. (Sort of---it doesn't turn off the
locale specific mapping in filebuf, which makes its actual
semantics rather vague.)
Note that at present, it is *only* used in filebuf and the
[io]fstream; it is not used in the basic iostream idioms. This
means that anyone using it is aware of the derived type (filebuf
or the [io]fstream decorators). If you design a new streambuf
type, which needs different modes, it's up to you whether you
reuse std::ios::binary, or define your own mode options. In
general, I think I'd use std::ios::binary if the default mode
corresponded to some sort of text mapping (say converting lines
into separate records), and the other mode were something more
or less transparent.
Examples I can think of are:
- writing multiline text into a windows text box (where you need \n
-\r\n conversion)
Text formatting, in sum. But do you ever want to provide the
transparent mode?
- writing text an HTTP GET request (which again I think needs \n >
CR, LF conversion)
At a lower level. HTTP (application layer) is based on Internet
ASCII (presentation layer), at least in the header. In this
case, you do need the two modes, *but* you need to change them
dynamically---one mode for the header and other text data, and
the other for binary data.
Arguably, you might want a different mode for every filetype
handled. And of course, you'd want to ensure standard ASCII for
the header, but an encoding specified in the header for the
remaining text. Except that if the remaining text is HTML---a
relatively frequent case---it's also possible that the encoding
be specified in the <head>...</headsection of the document.
There are different ways of handling this, but a on/off switch
when opening the file isn't sufficient. (Of course, if all you
want to handle is the GET command, then there is only a header,
and you map '\n' to CRLF, without an option to not do so.)
- writing text to some network protocol which needs lines terminated
by ASCII LF (some Mac compilers use(d) '\n'==ASCII CR because that
allows ios::text to be a no-op for filebuf).
Again, either you don't want to support transparence, or you'll
likely have to support changing modes dynamically.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See
http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]