Re: concrete example on "inheriting" from ostream
FYI, there are two classes that inherit from ostream, ofstream and
ostringstream. Both only add a streambuffer and some gluecode. Both don't
change the way things are formatted and they can't really do that either.
Anyhow, let's look at your issue in detail...
AlfC wrote:
This message is actually a request for small working example or at
least a clear explanation on how to build a class that behaves almost
like a std::ostream except that some types are printed with a different
format.
In general, that is rather easy: define a class (which might contain an
ostream for convenience) and define overloaded operator<< for it which do
what you want. This is the brute force approach, but it isn't necessarily
wrong.
I had been thinking that some types can be printed to streams and
change the format according to the context, where the context is
specified by the type of stream it self. in other words I have the idea
of creating different streams for printing data in different format.
Yes, the format can change depending on the context. Now, the context is
not the type of the stream. The context is rather the so-called 'locale'
which contains information about (typically culture-specific) formatting
rules, e.g. 3.141 is a fractional number in some cultures and roughly
three thousand in other languages.
for a simplified example, supose I want to print a complex number in
two different formats although integer types are always written in a
default cannonical way.
std::ofstream ofs("ofs.txt");
ofs<<std::complex<double>(3,4)<<" "<<9<<std::endl;
should print the expected "(3,4) 9" to a file
however I would like to have a different stream that works in another
format:
custom_ofstream cofs("cofs.txt")
cofs<<std::complex<double>(3,4)<<" "<<9<<std::endl;
should print "3+i4 9"
the idea is that for many types, custom_ofstream, will just behave and
print like std::ofstream, for several other types the printing
phylosophy will be different (like a more natural language output). eg.
for strings, integers and doubles and other types I want to keep the
standard printing, for specific other types (some builtin, like
complex<double> and some other user defined) I want to change the
default behaviour.
Okay, maybe the brute-force approach is the only one that gives you enough
control about how things are formatted. Concerning the outputting of
complex numbers, I'm not even sure if that is governed by a facet of the
locale, but for strings I am sure that there is no such thing as a locale
dependence so you can't adjust the locale there.
Anyhow, there is another way that goes somewhere in between doing it
completely safe but still rather conveniently. The idea is that you use
formatters like e.g. this:
ostream& out = ...;
complex<double> n = ...;
out << format1(n) << " == " << format2(n) << std::endl;
format1() and format2() are both functions that format a complex in
different ways. In case you want to call the same code that writes a
number in different ways, you need to attach that information to the
stream somehow. The invoking syntax then changes to this:
out << format_complex(n) << std::endl;
while format_complex is a structure defined like this:
struct format_complex {
format_complex(complex<double> x): value(x) {}
complex<double> value;
};
ostream& operator<<(ostream& out, format_complex const& fmt) {
/* determine output format and write accordingly */
return out;
}
The part left out above is where it gets tricky. The hard way would be to
write a locale's facet and work with that - if you want that, get hold of
Langer and Kreft's "C++ IOStreams and Locales" from your favourite
bookshop. The simpler though less powerful way is to use the
xalloc/iword/pword approach. Those three are functions of streams that
allow you to allocate a unique token (xalloc) and attach a long int
(iword) or void pointer (pword) to a stream. The information therein is up
to you to define.
int complex_format_token(){
// only once!
static int const token = ios_base::xalloc();
return token;
}
// note: defaults to zero if not previously set
long get_complex_format_type( ostream& out) {
return out.iword(complex_format_token());
}
void set_complex_format_type( ostream& out, long fmt) {
out.iword(complex_format_token()) = fmt;
}
ostream& operator<<(ostream& out, format_complex const& fmt) {
switch(complex_format_type(out)) {
... // format here
}
return out;
}
[Note that I wrote this out of the top of my head, I'll leave fixing the
occasional glitch to you. ;) ]
Now, what are the drawbacks?
The biggest drawback is that if you simply write the complex to the stream
like always it will still get written as always. That means that you can't
customise code you don't control, e.g. in a library. Also, it means that
you can forget to use the special way. If you used locales, you could
customise even binary-only modules of your program, but it is way more
complicated and it doesn't work for strings anyway. If you used the real
brute-force approach you could encapsulate the whole formatting issue
there so it would be impossible to forget using it. However, it would
require other invasive changes throughout the program because of the
switch from ostream to your type.
Looking in previous topics in the group I found that doing something
like this requires a more involved approach consisting in first
creating a class "custom_streambuf" that is derived from std::streambuf
and then creating the "custom_ofstream" class as privatelly derived
from custom_streambuf and publicly derived from ofstream.
The streambuffer is a plugin whos task is to perform the actual IO. Apart
from characterset conversion it has nothing to do with formatting!
This question (or similar questions) had been around the group many
times however I didn't find a working code that reaches the point where
"friend operator<<(custom_ostream& , type const&)" or eventually member
"custom_ostream::operator<<(type const&)" is defined.
The reason you can't find working code is that there is none. Two reasons
for that:
1. Usually, you don't pass around ofstreams but plain ostreams (the
baseclass). So, in order to decide which inserter to use, only the
baseclass is considered.
2. Even if you didn't pass around the baseclass, as soon as you invoke a
non-overloaded inserter it would return a reference to the base! Let us
consider an imaginary stream which has an overloaded inserter for doubles:
xyzstream out;
out << 3.14 << " is the same as " << 3.14 << '\n';
^^1 ^^2 ^^3 ^^4
For inserter #1, it considers xyzstream and double as parameters, which
calls the overloaded version. For inserter two, it doesn't find a suitable
one for xyzstream so it considers the baseclass ostream. However, that
inserter has this signature:
ostream& operator<<(ostream&, double);
so afterwards the information that it is an xyzstream is lost! The calls
thereafter only consider the ostream baseclass.
Does any one have
a complete small working example of how to define output streams that
behaves much like a standard output stream except than *some* specific
types are printed in a different format?
I particular I am interested in the approach that uses "virtual
private" inheritance (which sounds very professional).
If you inherit an ostream privately (which is not much more than
containment), it won't be considered as possible conversion when calling
an overloaded function like in the xyzstream example above. That means
that you will have to redefine all operator<<, but it also means you can't
forget doing that, which might be a plus. If you don't want to customise,
you can simply forward the calls:
friend xyzstream& operator<<( xyzstream& out, double c){
static_cast<ostream&>(out) << c;
return out;
}
....so that might be a viable solution, too.
HTH
Uli
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]