Re: Having trouble with streams....
On Aug 11, 6:19 pm, SpreadTooThin <bjobrie...@gmail.com> wrote:
I need to go over both of your posts with some care... Give
me a moment... In the mean time I wrote this last night, but
didn't press send, now you've both replied, so forgive me if
you have already answered some of these questions.
I have a class that is used for logging debug information in
code. It was based on Fred Fish's debugging facility.
I'm not familiar with Fred Fish's debugging facility, but I've
implemented several configurable logging facilities.
Basically it produces logs like:
className::MethodName
message
>someOtherClass::SomeMethod
more messages.
<someOtherClass::SomeMethod
<className::MethodName
The code looks something like
dbgFile dbg("\tmp\test.log");
void className::MethodeName(void) {
dbgEnter();
How does dgbEnter() get the name of the function? I regularly
use macros in such cases, in order to insert __FILE__ and
__LINE__ automatically. There is no similar possibility for the
name of the function, at least not in C++ (C has __FUNC__), so I
require the name of the function as an argument.
I also create an object with the macro here, and log the leaving
of the function in the destructor.
SomeOtherClass x;
dbg << "message" << std::endl;
x.SomeMethod();
dbgLeave();}
void someOtherClass::SomeMethod(void) {
dbgEnter();
dbg << "more messages" << std::endl;
dbgLeave();
}
There are other methods to turn on and off debugging.
The class doesn't need to write methods for each type it
outputs as all logging is done through use of operator <<.
So as long as the class implements operator<< on an ostream
the logging should work.
The *usual* solution for this is to provide a template member
operator<<, which forwards to the underlying stream. There's no
reason, however, that your solution won't work.
The part that to me is prone to break down is that dbgFile
inherits from std::ostream. Various people tell me this is a
no no.
Those people know nothing of how iostreams work. Even in the
standard, ofstream and ostringstream inherit from ostream, and
in practice, it's very, very rare to use an ostream which isn't
actually some type derived from ostream.
The debugger is built on two classes:
dbgFile (What the user uses)
dbgBuf (Used to control nesting level indentation)
class dbgFile : public std::ostream
class dbgBuf : public std::streambuf
The dbgBuf is used just to catch the end of line and the
begging of the next new line. At the beginning of the new
line prior to outputting any text, tabs are produced, one per
nesting level.
A filtering streambuf, in sum.
dbgEnter and dbgLeave are macros for like, dbg.enter(string
classname, string methodname)
I think i need to clarify two things,
1) is the inheritance from std::ostream ok, and if not how
should i proceed?
There should be no problem with it, although I've more often
seen (and used) containment, with member template operator<<
forwarding to the actual stream. (Containment has the advantage
that you can arrange to not actually format if the logging isn't
active, i.e.:
template< typename T >
Debug& operator<<( T const& obj )
{
if ( active ) {
myStream << obj ;
}
return *this ;
}
.. Of course, if you set the streambuf pointer in the
base ostream to null, its << operators shouldn't do anything
either.)
2) Does anyone have a better suggestion then using streambuf
for end of line detection?
I think it's the standard solution. It's the solution I
regularly use; I'd refer you to my code and the articles I
wrote, but my provider seems to have made my site inaccessible
for the moment. (I think that they've just changed the URL's to
access the site, but I don't know the new URL.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34