Slashdot Mirror
Printf Debugging Revisited
gsasha writes "After long nights spent in debugging, w e have developed a C++ logging facility geared for debugging - and an article that describes our debugging methodology.
The article consists of two parts: the first one describes the basics of the method, and the second one presents advanced techniques (to be completed if there is enough reader interest).
Happy debugging!"
Happy debugging!"
I didn't read the paper, but I looked at the code (for me this is usually more telling).
The first thing that jumps out at me is the coding style. Very junior programmer-ish. College student maybe? The style has that "everything crammed together" very diffcult to read feel. When I dug deeper I found the system to be over-designed and not well implemented.
Nice try though, get some experience then try again.
I've found that a simple C based logging facility is much more versatile. It can be used from C or C++ plus most programming languages and applications support calling external C libraries also.
The ratio of people to cake is too big
When I learned Common Lisp, the first macro I did was for printing debugging. It reads the expresions it is debugging, prints it (and shortens it with "..." if needed), evaluates it, prints the results and returns the results.
What a monster you might say. Lets fist see an example of it's use:It's done like that (and it's actually readable when indented properly):Most of the hard work is taken away by the ability of the program to read itself, by dynamic typing and by the notion that there are no statements, only expressions. That being said, I don't claim that you should never use C++, just that it lacks introspection and that it makes printing debuging a lot harder.
why not a link to a more professional and better-designed debugging library instead? The author has made insane efforts to handle all kinds of error conditions which it looks like these kids haven't even thought of.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
My first reaction to this was, who hasn't?
I agree with some of the other posters that their code has some, well, "interesting" features. I have to say it never would have occurred to me to use strcmp on a compile-time constant in a member initialization.
That they use, but don't derive from, std::ostream for this is another example. It's not exactly trivial to do so, but it's also hard to argue against not doing it for something like this without good reason. But since there's not a single comment in the source files except some revision control macros we're just left to wonder.
As many have said, this has been done before. One of their main macros isn't even correct. Ie.,
...
r y-manual&entry=logger.htm
r y-manual&entry=tracer.htm
#define LOG(logger) if ((logger).is_active()) (logger).os()
This will break if one writes:
if (value == 0)
LOG(xxx) "hello" endl;
else
The "else" gets interpreted as being attached to the "if" inside the LOG macro when it shouldn't.
It should be written as:
#define LOG(logger) if (!(logger).is_active()) ; else (logger).os()
For a much more expansive trace/log system see OSE at:
http://ose.sourceforge.net
and specifically
http://ose.sourceforge.net/browse.php?group=libra
and
http://ose.sourceforge.net/browse.php?group=libra
The OSE library has had this stuff for over ten years now.
// Constructor:
Logger(const Logger& enable2 = *(Logger*)0);
(Trimmed to trick the lameness filter.)
Pure. Evil.
And don't go telling me "that's perfectly valid," cause you know what? I don't care if the C++ compiler accepts it, and I don't care if you do it in your code. That is just pure evil.
Education is the silver bullet.