Re: concrete example on "inheriting" from ostream
AlfC wrote:
Typically, when you are wrapping an iostream, the operator<<
functions are member templates. Which shouldn't prevent you
from providing custom versions; all other things being equal,
overload resolution should prefer the non-template version (or
you can explicitly specialize the template function for the same
effect).
However in your example you use a template global fuction
operator<<(custom_ostream&, T const&).
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).
/** code **/ /** attention to the namespace qualifier, all this is
meant to be inside namespace latex**/
I'd definitly change the names. You're bound to encounter users
you do a "using namespace std;", and then all sorts of confusion
will result.
suggestions? I was thinking in changing latex::ofstream into
latex::document, however I didn't come out with a good replacemet for
latex::ostream without breaking the logical name pattern.
latexostream, latexofstream, etc.
The standard already has two different sets of iostreams: the
"normal" ones, and the wide character ones. Just follow their
example, replacing the w with latex (or LaTeX, or whatever).
[...]
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.
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.)
struct FileBufWrapper
{
public:
FileBufWrapper( std::string const& filename,
std::ios::openmode mode )
{
myFilebuf.open( filename.c_str(), mode ) ;
}
streambuf* filebuf()
{
return &myFilebuf ;
}
private:
std::filebuf myFilebuf ;
} ;
class ofstream : private virtual FileBufWrapper,
public latex::ostream
{
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. 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.
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.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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! ]