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!"
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.
If you look at the links, you can see they are both PhD students in the Technion institute of technology.
It's actually pretty strange the coding style is like this, specifically the hard coded functions like get_enabled1 or set_red instead of variables and constants like get_enabled(unsigned num) and set_color(Logger::color col).
I'm particularly surprised because I study in the same institute and faculty as they do and the programming courses we have are pretty demanding and specifically point to code reusability instead of code copying.
^_^
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.
The manipulators are particularly awful. They're a bunch of little functions that are copy/pasted just to change a string literal. Some of them don't even change the literal!
std::ostream& set_dark_white(std::ostream& os)
{
if (!LoggerConfig::is_nocolor()) {
const char* buf = "\x1b[0;37;40m";
os.write(buf, strlen(buf));
}
return os;
}
std::ostream& set_gray(std::ostream& os)
{
if (!LoggerConfig::is_nocolor()) {
const char* buf = "\x1b[0;37;40m";
os.write(buf, strlen(buf));
}
return os;
}
std::ostream& reset_color(std::ostream& os)
{
if (!LoggerConfig::is_nocolor()) {
const char* buf = "\x1b[0;37;40m";
os.write(buf, strlen(buf));
}
return os;
}
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.
While their styles will vary greatly, old timers will almost uniformly prefer an easy-for-others-to-read style.
Easy-to-read for whom? Easy to read for an absolute beginner? Easy to read for an expert programmer?
There is no style that works for every reader--a style that makes code easy to read for beginners can obscure patterns and shorthands that make code easy to read for expert programmers.
Well, if you didn't RTFA, then you missed the point. The article is not about "oh, we wrote this wonderful logging mechanism". It's about the *methodology* of debugging almost exclusively by logging (as opposed to *sometimes* doing postmortem analysis by looking at the logs).
It's about leaving the logging code inside and improving it, rather than throwing it out shortly after it's used.
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.
First: my fault ;)
Second: because you don't need a much more advanced logging facility for the intended use.
Fourth: Whoa! That's easy: #define LOG(x) if (false) os. But actually, yes, I do ask people to not throw logging out once it's there. The reason it's not expensive when not used is that the branches in the "if(is_active())" do not change throughout the program, and thus are predicted very well and cost very little. I actually did measurements about the overhead of the mechanism and found it to be very small.
Fifth: We have used this methodology in several very complex projects, and with very good results. You are free to use other debugging methods if you wish.
And anyway, an article such as this is a fine way to research on how will people use my utility :)