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!"
First look at the code... looks rather primitive[0]. Guess I have to read the paper to figure out what's new here?
Don't think I will.
[0] Which isn't necessarily a bad thing, but you'd wonder why it's here to begin with.
What's wrong with a simple link to the article? It already contains download links and links to the authors' websites. Splitting words up into multiple links isn't just annoying, but confuses people who use screen readers and Google. Editors, it's your job to massage submissions into a decent format.
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
Hasn't this wheel already been invented many many times?
How about Log4C++, a port of the canonical Log4J logging package for Java.
It's 10 PM. Do you know if you're un-American?
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)
This is a pretty standard technique, which has been used by all sorts of software sytems for decades now.
Are you adequate?
Because its old news. Everyone who's ever written medium and larger sized programs has written their own debug library, and they all act 90% the same. Its a quick 5 minute hack job to put one together.
I still have more fans than freaks. WTF is wrong with you people?
Show me on the doll where his noodly appendage touched you.
If you'd actually read the comments, even if you hadn't looked at the code, you'd have some idea just how "hardcore" this is.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Oh. Right. Nevermind.
"Eve of Destruction", it's not just for old hippies anymore...
SLASHDOT: news for people who can't concentrate on work or have no life at all and got tired of yelling back at the TV.
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.
As many other, I once wrote quite an extensive logging library.
You can find it here along with an article I wrote what I though logging should support:
http://www.bluefish.se/aquarium/lime.html
Actually, it's not academic stuff and never meant to be. It's a simple article describing a nice methodology... and actually, it's not that much about the logger implementation (it isn't at all), but about how using debugging by logging consistently is a powerful technique.
// 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.
using debugging by logging consistently is a powerful technique
:)
My co-worker (also called Sasha, incidentally) holds the same belief, but it seems the main reason for this is that he doesn't know how to use a real debugger
In this world nothing is certain but death, taxes and flawed car analogies.
IMHO, a more general (and interesting) technique is meta-programming. You can automatically add code. See http://mozart-dev.sourceforge.net/pi-tracer.html for an example.
-- Did you try Tao3D? http://tao3d.sourceforge.net
Crash dumps only go so far. They're good for picking apart a program that crashed, but many errors are logic errors: being asked to add X+l (lower case L) and having the coder write X+1 (digit one) won't crash a program, but it won't always produce correct results, either. And it's very difficult to find when the lower case 'L' usually contains the value one anyway, except in these critical error situations. Logging lets us examine snapshots of the internal state at critical points in the execution. It also gives us flow, which answers questions such as: what did the user type, when did they type it, and "how many fricking times did they hit the damned enter key??? Idiots!"
And yeah, we've got a lot of people who can't read dumps. We have a few who apparently never learned the difference between hex and decimal. It's becoming obvious to me that schools are not emphasising the machine level of programming any more, but focusing only on the highest level of languages. There are degreed java coders coming out now who barely understand what byte code is, let alone the fact that a virtual machine still has to interpret that data before a CPU can execute it.
Of course, that's just my crotchety old-guy opinion. I could be wrong.
John