Printf Debugging Revisited

← Back to Stories (view on slashdot.org)

Posted by timothy on Sunday September 26, 2004 @06:48AM from the visit-nicely-now dept.

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!"

59 comments

aah, academic stuff by Sir+Haxa1ot · 2004-09-26 06:55 · Score: 0

Nothing speaks more of an academic paper, than a pair of google ads slapped on the side of it.

You guys should check out Slashdot's advertising section.

--
Nader-2004
1. Re:aah, academic stuff by gsasha · 2004-09-27 00:37 · Score: 2, Interesting
  
  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.
2. Re:aah, academic stuff by rjshields · 2004-09-27 06:03 · Score: 1
  
  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.
3. Re:aah, academic stuff by plover · 2004-10-01 03:09 · Score: 1
  
  We have a different problem. Our software is widely distributed around our corporation, through sometimes slow networks. We can't remotely debug, but we're expected to have an answer for every software failing. Logging is the best way we've found to be able to determine root causes.
  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
Looks primitive. by Anonymous Coward · 2004-09-26 06:58 · Score: 2, Insightful

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.
1. Re:Looks primitive. by gsasha · 2004-09-27 00:40 · Score: 1
  
  You exactly missed the point. Everyone can write a logger, and ours is not an unusually smart one. The point is though, that *if you use loggers consistently, it'll be easy to debug*.
  But oh well, why did I expect a Slashdot reader to RTFA.
2. Re:Looks primitive. by Viking+Coder · 2004-09-27 03:55 · Score: 2, Insightful
  
  Look, friend - first you're responding to an Anonymous Coward. Expecting an AC to RTFA is wishful thinking.
  
  Second, he's right - your code is rather primitive, as you admit. Why not start with a much more advanced logging utility, and then speak about using the logging consistently?
  
  Third, if your whole point was about a methodology, then talk about the methodology. Reading your article, it doesn't read like that - it reads much more like a User's Manual for how to use your code.
  
  Fourth, what makes you think that using loggers consistently is the answer? In fact, I can't see how to turn off your code (make it compile down to nothing, not merely something small) in release mode. You're essentially asking people to always use logging, for the sake of sometimes doing debugging.
  
  Fifth, have you actually researched how people will use your utility, or are you just making a blanket assertion that "it'll be easy to debug" if you merely follow some trick? Gotcha on this one - you're essentially pitching the idea of a silver bullet, while stating that "there is no silver bullet in sight." Well, which is it?
  
  Look, you might have some good ideas - but when pitching a methodology, speak about it in terms of a methodology, and don't lecture down to some random Anonymous Coward on Slashdot. That's like Bill Gates stopping in the supermarket to argue with some woman about whether "Start | Shutdown" makes any sense.
  
  --
  Education is the silver bullet.
3. Re:Looks primitive. by gsasha · 2004-09-27 04:44 · Score: 2, Interesting
  
  Ok then.
  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 :)
4. Re:Looks primitive. by Viking+Coder · 2004-09-27 05:04 · Score: 1
  
  First: fair enough. =)
  
  Second: I would actually argue that your code is far more complicated than it needs to be, for the intended use.
  
  Third: Apparently there is no third. =)
  
  Fourth: Sure, I could change your code to make it go away, but I think it would be much better if your code had its own mechanism for going away. I would tend to agree that anything inside "if (false)" should mostly compile away - so that's fair. I'd like to see a "#ifdef DEBUG" or somesuch in your code for that case.
  
  Fifth: It's not about how many, it's about how they use it. Conducting actual research on how people use it would really add some oomph to your work.
  
  And finally a new comment: Why not output everything, and then have filters for the information that you're looking for? In other words, single-shot sessions. For instance, you first discover that the bug is in cycle 1,000,000 and then look for it again. Why not output for every cycle? Probably because it's cost prohibitive, right?
  
  I mean, your fundamental message is don't remove debugging printf's, have a mechanism to run them or not! which is a good message. I think it just gets lost in the details of everything else you say, and it's not actually a new message.
  
  --
  Education is the silver bullet.
5. Re:Looks primitive. by gsasha · 2004-09-27 09:00 · Score: 1
  
  Second: The complexity sits where it is actually necessary - you need powerful control of what and when is printed (see below). The critical path of the code, the printing itself, is quite straightforward.
  Fourth: Well, I could add some "#ifdef LOG_DISABLE". On the second thought, I'll do exactly that.
  Your new point: you are close. Yes, it would be prohibitive, both space-wise and performance-wise, to print everything (in the case I describe, it can easily be 100K per cycle at maximal output).
  But the point is not only that. I go to great lengths to make sure that only what you need to see is printed.
  Your approach would require printing so much markup with the logging, that the content would drown, and it would need to be extremely readable to be effective. When something complex is going on in the program, you will need any bit of readability to get it.
  So, the point of the article is not only to leave printfs inside, but to include a mechanism that would enable very precise control of what is printed and what isn't.
  Point taken though. I'll see if I can improve the article to convey it better.
WTF's up with the links? by Anonymous Coward · 2004-09-26 06:58 · Score: 1, Insightful

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.
1. Re:WTF's up with the links? by slashjames · 2004-09-27 03:57 · Score: 1
  
  That's assuming the editors are paying attention. Given dupes and the horrid IT color scheme (with LOTS of complaints and no action taken), it's likely they are not. I'll consider getting a subscription IF these types of issues are resolved. Until then, why bother?
Some comments by Cthefuture · 2004-09-26 07:08 · Score: 4, Insightful

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
1. Re:Some comments by jeif1k · 2004-09-26 07:36 · Score: 1
  
  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.
  
  The first thing that jumps out at me about your post is that you make snap judgements about people's experience and background based on how much whitespace they use. Very junior programmer-ish of you. Are you a college student, maybe?
2. Re:Some comments by Cthefuture · 2004-09-26 07:50 · Score: 0, Flamebait
  
  Stupid is as stupid does.
  
  --
  The ratio of people to cake is too big
3. Re:Some comments by Anonymous Coward · 2004-09-26 08:24 · Score: 0
  
  I suppose it's a start that you realize this important fact about yourself.
4. Re:Some comments by Brandybuck · 2004-09-26 08:45 · Score: 4, Insightful
  
  Actually my experience is that you can tell how junior a programmer is by their style. While their styles will vary greatly, old timers will almost uniformly prefer an easy-for-others-to-read style. There are of course exceptions. Some junior programmers have been exposed to professors/managers/reviewers who won't accept unreadable code, and some senior programmers got tagged as "heroes" and have never had to maintain someone elses code.
  
  --
  Don't blame me, I didn't vote for either of them!
5. Re:Some comments by ssimontis · 2004-09-26 09:17 · Score: 1
  
  I don't know about this. I am probably an intermediate C+ programmer at best, programming for about 2 years now. From the start, I made sure to define a style and keep it. At first, I did have some trouble trying to remember all my style rules, but now I make very few style mistakes. However, I also have never attended a programming class and have learned from books and guides.
  
  --
  Scott Simontis
6. Re:Some comments by Soul-Burn666 · 2004-09-26 09:58 · Score: 2, Interesting
  
  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.
  
  --
  ^_^
7. Re:Some comments by SamBeckett · 2004-09-26 10:27 · Score: 3, Funny
  
  Can you please point me to a good C+ compiler... gcc keeps complaining about my .cp files.
8. Re:Some comments by Anonymous Coward · 2004-09-26 10:51 · Score: 0
  
  A strict style and an easy to read style are not the same things. A strict style can be enforced by a code beautifier. If you can't do better than a beautifier . . .
9. Re:Some comments by Anonymous Coward · 2004-09-26 12:54 · Score: 0
  
  I have plenty of experience, and unreadable code is IMHO one of the main indicators of bad programming habits.
10. Re:Some comments by Anonymous Coward · 2004-09-26 13:55 · Score: 1, Interesting
  
  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;
  }
11. Re:Some comments by jeif1k · 2004-09-26 18:39 · Score: 2, Interesting
  
  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.
12. Re:Some comments by gsasha · 2004-09-26 22:03 · Score: 2, Interesting
  
  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.
13. Re:Some comments by Anonymous Coward · 2004-09-27 01:40 · Score: 0
  
  Can you please point me to a good C+ compiler... gcc keeps complaining about my .cp files.
  
  "The slightly shorter name "C+" is a syntax error; it has also been used as the name of an unrelated language."
14. Re:Some comments by phats+garage · 2004-09-27 02:06 · Score: 1
  
  If it was hard to write, it should be hard to read.
  (Theres like a thousand versions of that out there.)
15. Re:Some comments by rjshields · 2004-09-27 06:41 · Score: 1
  
  Very junior programmer-ish
  
  Indeed. Without wishing to be derogatory, another thing that sucks of junior programmer is that the author considers this insignificant hack important enough to be worthy of being on slashdot. The delusions of grandeur go with the territory.
  
  Yes, it's mildly interesting but the fact that it badly reinvents a wheel already invented many times over makes it less so.
  
  --
  In this world nothing is certain but death, taxes and flawed car analogies.
16. Re:Some comments by mce · 2004-09-27 06:42 · Score: 1
  
  Sadly, the "experience yields more readable" code idea is not generally true.
  The most experienced (in terms of years of experience: more than 20 to be precise) (ex-)coder on my current project prefers an absolutely horrible coding style if you let him do as he pleases. Utterly unreadable for anyone but him (endless lines that wrap on even the widest of screens; NO blank lines; the weirdest indentation convention I ever saw; countless "this was/is experimental or old code" sections that have been commented out without any documentation of why they are commented out nor of why they are not simply deleted; debugging code that can only be enabled by uncommenting it line by line and recompiling the lot instead of using the "setenv"-based debugging mechanism that we provided him with to switch on/off debugging code at run time; ...).
  
  --
  Linux user since early January 1992.
17. Re:Some comments by Brandybuck · 2004-09-27 08:28 · Score: 1
  
  Was he one of the exceptions I mentioned? No rule of thumb is ever 100% accurate, but my personal experience tells me that the more experienced the coder the more likely it is that their code will be readable. This is experience in coding, not mere longevity. My boss who was coding twenty years ago but hasn't coded in the last fifteen doesn't count.
  
  --
  Don't blame me, I didn't vote for either of them!
18. Re:Some comments by mce · 2004-09-27 08:56 · Score: 1
  
  Of course he may be one of the exceptions. All I wanted to say is that I've seen from personal experience that experienced coders can do things so horrible that one wouldn't believe them possible. This guy did spend all those years coding, by the way.
  
  --
  Linux user since early January 1992.
19. Re:Some comments by bluGill · 2004-09-27 11:10 · Score: 1
  
  But it is a good standard? In particular, in order of importance, is the A) the standard everyone else on the project uses, and B) a common standard used by other successfull projects?
  I have my own personal preferred coding standard. It is fairly close to B, but it fails in A at work. I get into a lot of trouble over this, and I'm wrong. Even though if I showed both (the company and my) standards to the world most programmers are likely to prefer mine (just a guess, but based on various style guides) to the company. However the company standard always rules because several better standards combined is worse than a okay one. (though I'm sure you could design a standard that was worse)
20. Re:Some comments by Soul-Burn666 · 2004-09-27 13:02 · Score: 1
  
  moreover, why double not?
  as in !LoggerConfig::is_nocolor()... it's much clearer to have it LoggerConfig::isColor().
  Another thing:
  won't it work just to do
  os "\x1b[0;37;40m";
  instead of those 2 lines?
  I might be wrong here, if someone can correct me.
  
  --
  ^_^
21. Re:Some comments by Anonymous Coward · 2004-09-27 13:44 · Score: 0
  
  Not true. If you've ever seen a truely skilled programmer's style then you would know better.
  
  It usually comes with experience. A good programmer's code is easy to read by anyone. As a consultant I write code that is read by "experts" (the programmers I'm working with) and also unskilled individuals (the people who are going to pay me for that code). I always get comments from both groups about how easy my code is to read. They've usually never seen anything like it.
  
  It comes with experience.
22. Re:Some comments by xygorn · 2004-09-27 20:35 · Score: 1
  
  For those of us just setting out to get that experience, is there a style guide of some good starting points to follow? Also, can you point me towards some good code that I can try to learn from? I've found that identifying hard to read code is easy, but figuring out how to correct it is hard.
  
  --
  I am a sig. I wish I were a more creative sig, but I am not. I guess everyone has something to strive for.
23. Re:Some comments by Anonymous Coward · 2004-10-01 02:16 · Score: 0
  
  I've got one of those on my team.
  He's got many years of coding experience, but has learned absolutely nothing about how to format his code so that other people can read and/or maintain it.
  More than one developer has complained to me about it, and I've talked to him about it on several occasions, but he doesn't change. I've found it easier to shut up and run his code through a pretty-printer rather than try to convince him of the error of his ways.
  He's not stupid, by any definition, but it's frustrating as all get out.
  Posted anonymously so he doesn't see that I wrote this :-(
24. Re:Some comments by plover · 2004-10-01 02:35 · Score: 1
  
  He needs the length of the buffer to pass the size to the .write() method. By calling strlen() he avoids the problem created by defining the literal in once place and the length of the literal in another.
  Now, why he didn't simply use the << operator on the literal string allowing the functionality of strlen() to be encapsulated by the routine that actually cares about the string's length is beyond me... :-) Oh, I bet that's exactly what you were trying to say but you didn't encode the < character with the < string in your HTML.
  There. You may now feel validated by a second opinion. (And I completely agree with your opinion regarding the confusing nature of the "double negative" coding style as well.)
  
  --
  John
log4c++ by Hard_Code · 2004-09-26 07:14 · Score: 2, Insightful

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?
1. Re:log4c++ by Leffe · 2004-09-26 07:23 · Score: 1
  
  > Hasn't this wheel already been invented many many times?
  
  No big deal, I write a new logger for every project I write, it's a simple 5 minute hack.
2. Re:log4c++ by Mysteray · 2004-09-26 11:24 · Score: 4, Interesting
  
  we have developed a C++ logging facility geared for debugging
  
  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.
C++ makes it hard by YGingras · 2004-09-26 07:34 · Score: 5, Interesting

It's hard to do a good printing debugger in C++. The lack of introspection throws most of the work in the hands of the pre-processor/developper.

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:
CL-USER> (+ 16 34 (- 6 7 8) (/ (* 3 (expt 4 1/2)) 2 3)) 42.0 CL-USER> (dbg (+ 16 34 (dbg (- 6 7 8)) (dbg (/ (* 3 (dbg (expt 4 (/ 1 2)))) 2 3)))) (- 6 7 8): -9 (EXPT 4 (/ 1 2)): 2.0 (/ (* 3 (DBG (EXPT 4 (/ 1 2)))) 2 3): 1.0 (+ 16 34 (DBG (- 6 7 [...] 4 (/ 1 2)))) 2 3))): 42.0 42.0
It's done like that (and it's actually readable when indented properly):
(defmacro dbg (expr) `(let ((val ,expr) (repr (format nil "~A" ',expr))) (if (> (length repr) 50) (format t "~A [...] ~A: ~A~%" (subseq repr 0 20) (subseq repr (- (length repr) 20)) val) (format t "~A: ~A~%" repr val)) val))
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.
1. Re:C++ makes it hard by Piquan · 2004-09-26 08:06 · Score: 1
  
  You might want to bind *print-length* and *print-level* fairly low when you're printing repr; that may eliminate some of the [...]s. For that matter, you may want to wrap that whole thing in a with-standard-io-syntax, in case some print variables happen to have funky values when it's called.
  Me, I tend to use (print `(foo before processing -> ,foo)) instead, but everybody's got their own style.
Instead of adverts for 2nd-year student projects by devphil · 2004-09-26 08:44 · Score: 4, Informative

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)
Wheel invented. News at 11. by Estanislao+Mart�nez · 2004-09-26 11:00 · Score: 1

This is a pretty standard technique, which has been used by all sorts of software sytems for decades now.

--
Are you adequate?
19 comments in 4 hours? by HotNeedleOfInquiry · 2004-09-26 11:33 · Score: 0, Offtopic

Here we have it folks, a hardcore stand-up programming topic and only 19 comments. Is Slashdot overwhelmingly populated with posers?

--
"Eve of Destruction", it's not just for old hippies anymore...
1. Re:19 comments in 4 hours? by AuMatar · 2004-09-26 11:56 · Score: 1
  
  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?
2. Re:19 comments in 4 hours? by Pseudonym · 2004-09-26 14:04 · Score: 1
  
  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});
3. Re:19 comments in 4 hours? by HotNeedleOfInquiry · 2004-09-26 14:18 · Score: 1
  
  Oh. Right. Nevermind.
  
  --
  "Eve of Destruction", it's not just for old hippies anymore...
BZZZZT! by Anonymous Coward · 2004-09-26 12:38 · Score: 0

Wrong. The correct answer is "yes". Thanks for playing!
Don't reinvent the wheel by pyrrhonist · 2004-09-26 12:51 · Score: 3, Informative
Don't reinvent the wheel. These facilities already handle logging better:
- Log4cxx
- Log4cplus
--
Show me on the doll where his noodly appendage touched you.
Interestingly... by Anonymous Coward · 2004-09-26 14:09 · Score: 0

Mister "e"'s homepage shows him in front of one of the main buildings of MS Research.
Don't take the criticism too hard guys... by museumpeace · 2004-09-26 14:56 · Score: 3, Interesting
Virtually every project of 10 or more engineers that I have been on in my 30 years of software dev has cooked up its own logging facility. You are on the back of a very crowded bus here. Depending on whether memory, disk i/o resources or realtime and multithread requirements reign in your application, rather different logging approaches are applicable. Being able to dump the Nth occurance is a nice feature but so many more are needed. THE BIGGEST DIFFERENCE I SEE between your logger kit and some I have used/written is that you published the code. A partial feature checklist I would be looking for:
- []has both compile time and run time mechanism to set severity thresholds.
- [] idenifies the process/thread from which the logging call is issued
- [] can generate some kind of event ID so context can be deduced even when the same message occurs many times.
- []timestamping: this can give you a poor man's perfmon with added programability.
- [] supports detection of recursion by indenting printouts that are called as you go deeper on the stack
- [] NOMENCLATURE REGULARITY: a syntax for timestamps, severity, function name from which print is called, etc so that you can automate [eg with AWK etc ] the sorting and dredging for clues in a long output run.
- []when not in use, can be "turned off" with no compile or run time overhead but still present as comments.
...there are more, believe me.
--
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.
Why is this on Slashdot at all? by Anonymous Coward · 2004-09-26 17:23 · Score: 5, Informative

As many have said, this has been done before. One of their main macros isn't even correct. Ie.,

#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=librar y-manual&entry=logger.htm

and

http://ose.sourceforge.net/browse.php?group=librar y-manual&entry=tracer.htm

The OSE library has had this stuff for over ten years now.
Apache Logging Services project by chip33550336 · 2004-09-26 18:52 · Score: 0, Redundant

This project is incubation, but it might be of interest :

log4cxx
My own thoughts by Anonymous Coward · 2004-09-26 19:10 · Score: 1, Informative

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
PURE EVIL by Viking+Coder · 2004-09-27 03:26 · Score: 4, Informative

// 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.
Gee, I wonder why no one uses LISP by Anonymous Coward · 2004-09-27 05:40 · Score: 0

(okay, (i'll) keep (that (in (mind) ) next)(time (I write, a) (program))))))))))))))))))))))))
Meta-programming. by descubes · 2004-09-28 07:15 · Score: 1

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
1. Re:Meta-programming. by plover · 2004-10-01 03:13 · Score: 1
  
  That's interesting, but what does that do for exception handling? It seems to me that it could interfere with exceptions thrown deep in the code that are expected to be caught at a level much farther up?
  I'm not a Java guy, so maybe I'm not catching all the nuances of the try/finally construct. It just looks like it could cause unwanted behavior.
  
  --
  John