As mentionned below, the main class you have to work with here
is streambuf; you derive from [io]stream only to automatically
create the correct streambuf.
And I can't remember any real application where I didn't do
this at least once.
Unless you're working in a multithreaded environment.
The real problem is the limited possibilties of error reporting.
Note that basic_istream has precious few virtual functions so deriving
from the istream gives you poor opportunity for influencing the way
the stream interface behaves. If you look at how *stringstream and
*fstream classes work, they generally have very little added
functionality. They usually just have an explicit constructor to set
up a particular type of streambuf and perhaps a few other methods
which are particular to the type of streambuf involved.
If you want to change where you are reading and writing from in
istream/ostream calls (e.g. istream/ostream on top of a socket) then
you are probably better of deriving a custom class derived from
basic_streambuf. Then you only have to worry about where to put/get
the raw bytes from and you can construct istream/ostream interfaces
around your streambuf to provide all the formatting capabilities. Any
functionality which uses the [io]stream classes will be able to run
with the new streambuf without modification.
In fact, this is the only way to change where you are reading
and writing from. The class derived from [io]stream is really
just for convenience, so that the user doesn't have to
explicitly declare his own streambuf object before declaring the
[io]stream object.
If you want the change the way in which various types are written out
then you may find that you can achieve what you want by implementing a
local::facet. You might, for instance, decide that integers should
really be serialised in a custom base64 style encoding. You could
then implement num_get and num_out facets. You can use this with the
standard iostreams by creating a new locale (std::locale has methods
for retrieving a copy of either the global locale or the "classic"
one), patching in your custom facets and imbueing (calling
ios_base::imbue) the stream with your custom locale.
That sounds a lot like abuse to me, and is likely to cause
trouble, since more complex objects like std::complex count on a
particular format. (In fact, std::complex doesn't even work
correctly in most European locales. That, I believe, is
considered an error, but I don't think the committee would
recognize it an error if e.g. it didn't work with
num_get/num_put facets which did binary output.)
The streams library is very flexible, but deriving from
istream directly probably won't give you the flexibility that
you are looking for.
No. It's more for convenience.
Deriving from ios is often done, however, for things like binary
streams, in order to get the standard error handling.
--
James Kanze (GABI Software, from CAI) email:
[email protected]
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
