Re: concrete example on "inheriting" from ostream
Habit, I guess. I've been using this technique since before
compilers supported member templates. If the getStream()
function is public, I don't think it really makes a difference
(but in fact, my own experience is with global functions and a
public getStream() function).
Luckly, it does make a difference because (for a reason I don't know)
member template have precedence over (friend) global templates. So
defining a member template hides the eventually every global template
that I still wanted to define for custom classes.
void set_math(){math_count_++; if(math_count_==1) os_<<"$";}
//technical issue with latex
void unset_math(){math_count_--; if(math_count_==0) os_<<"$";}
It would be nice to make the underlying buffer detect "$"
character and set the mathmode automatically. However this
feature is too complicated and probably overdesign.
You might consider some sort of manipulator for changing the
mode.
yes, set_math is just a prototype of this future manipulator. (however
it will be an "accumulative" manipulator, because unset_math just
decreases de counter and doesn't guarraty exit from math mode, even the
set/unset names are misleading, I was thinking in naming begin_math,
end_math)
One possible problem I was trying to explain is if the user sends for
example lout<<"$". the stream will enter mathmode without being
acknowlegded. This have to be done at the lever of the buffer object ((
think) of as a check when reading raw strings (such as std::string or
char* or char)
Alternatively, you could develop an Expression type, which
maintains a parse tree of the expression, and automatically
outputs it in math mode. (With perhaps a manipulator to
indicate whether the expression should be inline or not.)
yes, actually the idea was to make the "expressions" smart enought to
print them selves by means of a friend operator<<(latex::ostream&, type
const&), if for some reason a subexpression has to be printed in a
non-standard way it is responsability of the parent expression (or
node) to take appropiate actions (line accesing private data of the
child via friendship of using a formater --mentioned already in this
discussion--).
Let me mention that ultimatelly the output to latex will be just an
accesory, the expressions actually will be already there for solving
concrete problems. Some of them (maybe not all) could be output in
latex format.
Two quick questions here: why do we need a wrapper? why do we
need virtual inheritance?
The virtual inheritance ensures the correct order of
initialization. Even if we later inherit from the class
somehow. In practice, however, I think non virtual inheritance
will also work; at least, I've never encountered a case where it
wouldn't.
I think as long as it is declared as base before the other one and both
are non virtual then the first is guarrantied to be initialized first,
isn't it?
The issue becomes more complex, however, if we try to
support iostream, as well as istream and ostream, because this
means that we will be inheriting virtually from the ios base
class which needs to be initialized with the filebuf.
Do you mean that some derived class of latex::ofstream may be rederived
from filebuf and we are doing this just in case? (if so is good to
know)
As for the wrapper...
Deriving private virtual from std::ofstream should work, but you
don't really need an ofstream, just a filebuf. Whence the
simple wrapper. (Deriving private virtual from std::filebuf
doesn't work, because you have no way of getting the address of
the subclass to pass it to latex::ostream. For some strange
reason, calling a member function on the constructed base object
is legal here, but converting the this pointer to the base
object type is undefined behavior---and doesn't work with at
least one compiler I've used.)
I am lost here. It makes sense to me to cast *this into a base class
type, even at construction time (anc even if the base class haven't
been initialized), but, who knows?, it may not make sense for the
compiler implementators.
I'll admit that I'm not entirely clear as to the motivation
either. If I call a member function, I have to do the
conversion anyway, under the hood, in order to pass it the
correct this pointer. Still, I've actually used a compiler
where the conversion didn't work (but calling a member function
did!). Having been burned by it, I tend perhaps to be
over-cautious.
I'll try without the wrapper first and then if there is a problem I'll
introduce the wrapper. Yes, it must be frustrating when you are
fighting against an "ilogical" compiler and then two years later your
carefully designed workaround becomes useless because the compiler has
been "fixed".
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]