Re: concrete example on "inheriting" from ostream
Ulrich Eckhardt wrote:
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.
And neither wants too, 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.
If the goal is to define a new format (e.g. XDR), then this is
really the only solution. If the new format is text based, and
only differs from the existing ostream format for one or two
types, however, it probably isn't the best solution, even if it
can be made to work.
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.
<aside>
"Cultures" (or cultural environments) is the right word, and
not "languages". I'm not sure, but I think that 3.141 is a
fractional number in Canadian French, it's a little more
than 3000 in most French speaking environments, but there
are exceptions even in France, e.g. numerists who grew up on
Fortran:-).
</aside>
Anyhow, this is more or less a global distinction; while it's
not 100% clear concerning his case, his example (formats for
complex) suggests that it is not really what he is looking for
here. (Note too that playing with locale's is often playing
with fire. It's all too easy to end up modifying the input code
translation when all you wanted to do was use a comma as the
decimal.) My impression is that what he is looking for is best
handled by sicky format information. Since there doesn't seem
to be an appropriate flag free, he probably needs to use xalloc
to obtain some memory, and put the flag or other information
there.
One interesting possibility would be to use pword to store the
address of a functional object which does the actual formatting.
You can even declare a callback for specific stream events, so
that you could use reference counting or deep copy of the
functional object (although most of the time, there will only be
two or three of them, and it is much easier to just declare
static instances of them).
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.
The only think the brute-force permits that you cannot achieve
otherwise is to modify the formatting of pre-defined types.
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.
Complex numbers are output as two of the underlying types; these
are affected by the locale. The specification of << for complex
numbers in the standard is broken, however (even in the latest
draft), so it is hard to say more. Consider the following
sequence:
std::cout.imbue( "fr_FR" ) ;
std::cout << std::complex< double >( 1.2, 3.4 ) << std::endl ;
According to the standard, interpreted literally, this should
output:
(1,2,3,4)
Which is, of course, pattently ridiculous. (Supposing a normal
implementation of the locale "fr_FR" under Posix.) At the very
minimum, if the decimal point is a comma, the separator should
be a ';'; a better solution would be to introduce a list
separator character into numpunct facet.
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.
More correctly, they are funtions which return an object which
formats the complex. Often, in fact, they are the name of a
class, and the "function" called is the constructor. That's
probably not a good solution in the case of complex, however,
since you probably want to make the functions templates on the
underlying type, with template type deduction.
Note that this is not exactly what he asked for; with this
technique, you still have to specify the formatting each time
you output a complex.
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. ;) ]
I hate switches:-). This is a situation where virtual template
functions would come in handy, but since we don't have them...
I'd still define a hierarchy:
template< typename T >
class AbstractComplexFormatter
{
public:
virtual ~AbstractComplexFormatter() {}
virtual std::ostream& format(
std::complex< T > const& value ) const = 0 ;
static int pwordIndex()
{
static int const result = std::ostream::xalloc() ;
return result ;
}
} ;
Then define template derived classes for each individual format
wanted. The manipulators declare a static local object, and put
its adresse into the pword. (The problem with this, of course,
is that the manipulators are still dependant on the type of the
complex, with a different manipulator for each different type.
As I say, this is really a problem which needs templated virtual
functions.)
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.
Code he can change can use the above technique, invoking the
formatter. Code he can't change already uses std::ostream, so
the brute force approach doesn't work either.
--
James Kanze Gabi Software email: kanze.james@neuf.fr
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! ]