4 ms·

Occasionally I'll leave useful debugging log calls in there. It's a lot quicker to just uncomment the code when it's needed, rather than pulling that bit out fr

by barbs 13y ago

Occasionally I'll leave useful debugging log calls in there. It's a lot quicker to just uncomment the code when it's needed, rather than pulling that bit out from source code. Also, even more occasionally, I'll leave some incomplete code commented out as an obnoxious reminder to complete it later. This is especially useful if the code wasn't ever committed before, so checking it out via source-control isn't an option. The very fact that it's not really supposed to be there is a good motivator to implement it!

nostrademons 13y ago
Ideally you use log-levels and log-sources for this. Leave the logging calls in the production binary, but on DEBUG level. If there's a problem, bump the log-level up to DEBUG for just the subsystem you care about. Then you don't even need to recompile to get your logging information, you can just flip a flag - sometimes without even restarting the app. I'll admit to just commenting and uncommenting log lines before, though - learning how the logging systems of major programming languages work takes some time, and there's an up-front cost to starting to use them.
- warmwaffles 13y ago
  The other thing is, you have a bunch of wasted calls to a logger if you don't want any logging to take place. Minor, but if you are working on embedded systems etc... you won't be using a logger, you'll more than likely just comment out debug statements and leave them in. It all really depends on the application and how much performance is an issue.
  - nostrademons 13y ago
    Typically you wouldn't put a logging statement inside a hot inner loop anyway, as you'll get so much output when logging is turned on that it makes the logs worthless. For heavy algorithmic-intensive stuff, you'd often just record your loop counters, key invariants, and exit conditions, and then log them all at once when the algorithm exits. I have little embedded systems experience, but what I gather from talking to folks who do is that they also use logging APIs, but they avoid logging from inside a hot inner loop (their log statements are usually around startup/initialization and when the system receives certain inputs), and they use custom log writers that write the logs to a host server or desktop system when plugged in for debugging rather than taking up storage space on the device itself.
    - TeMPOraL 13y ago
      > Typically you wouldn't put a logging statement inside a hot inner loop anyway, as you'll get so much output when logging is turned on that it makes the logs worthless. For heavy algorithmic-intensive stuff, you'd often just record your loop counters, key invariants, and exit conditions, and then log them all at once when the algorithm exits. Debugging is a highly interactive art and sometimes operates inside a much faster feedback loop than that. Put those few log calls in the innermost loop, run it, scan the 20MB dump for a weird entry, fix, remove logger calls, and you're done in less time than it takes to consider which key invariants and exit conditions are worth tracking.
  - npsimons 13y ago
    One of these days, I really need to post my C++ logger class. Don't know if you're doing embedded C++, but I've used this class in VxWorks, and if you're not logging anything (the default build with NDEBUG does nothing), it should optimize away. For now, I can post a link to my inspiration: http://wordaligned.org/articles/cpp-streambufs http://wordaligned.org/articles/cpp-streambufs Extending from there is pretty straightforward, albeit you can hit some dark corners of C++ (I spent a few weeks tracking down a double link error caused by not templatizing an addition to the Logger that gave the capability to output to MSVS's debug window). This is also one of those very few cases in which I have justified using multiple inheritance, virtual inheritance, private inheritance, and templates.

by barbs 13y ago

nostrademons 13y ago

Ideally you use log-levels and log-sources for this. Leave the logging calls in the production binary, but on DEBUG level. If there's a problem, bump the log-level up to DEBUG for just the subsystem you care about. Then you don't even need to recompile to get your logging information, you can just flip a flag - sometimes without even restarting the app. I'll admit to just commenting and uncommenting log lines before, though - learning how the logging systems of major programming languages work takes some time, and there's an up-front cost to starting to use them.

warmwaffles 13y ago
The other thing is, you have a bunch of wasted calls to a logger if you don't want any logging to take place. Minor, but if you are working on embedded systems etc... you won't be using a logger, you'll more than likely just comment out debug statements and leave them in. It all really depends on the application and how much performance is an issue.
- nostrademons 13y ago
  Typically you wouldn't put a logging statement inside a hot inner loop anyway, as you'll get so much output when logging is turned on that it makes the logs worthless. For heavy algorithmic-intensive stuff, you'd often just record your loop counters, key invariants, and exit conditions, and then log them all at once when the algorithm exits. I have little embedded systems experience, but what I gather from talking to folks who do is that they also use logging APIs, but they avoid logging from inside a hot inner loop (their log statements are usually around startup/initialization and when the system receives certain inputs), and they use custom log writers that write the logs to a host server or desktop system when plugged in for debugging rather than taking up storage space on the device itself.
  - TeMPOraL 13y ago
    > Typically you wouldn't put a logging statement inside a hot inner loop anyway, as you'll get so much output when logging is turned on that it makes the logs worthless. For heavy algorithmic-intensive stuff, you'd often just record your loop counters, key invariants, and exit conditions, and then log them all at once when the algorithm exits. Debugging is a highly interactive art and sometimes operates inside a much faster feedback loop than that. Put those few log calls in the innermost loop, run it, scan the 20MB dump for a weird entry, fix, remove logger calls, and you're done in less time than it takes to consider which key invariants and exit conditions are worth tracking.
- npsimons 13y ago
  One of these days, I really need to post my C++ logger class. Don't know if you're doing embedded C++, but I've used this class in VxWorks, and if you're not logging anything (the default build with NDEBUG does nothing), it should optimize away. For now, I can post a link to my inspiration: http://wordaligned.org/articles/cpp-streambufs http://wordaligned.org/articles/cpp-streambufs Extending from there is pretty straightforward, albeit you can hit some dark corners of C++ (I spent a few weeks tracking down a double link error caused by not templatizing an addition to the Logger that gave the capability to output to MSVS's debug window). This is also one of those very few cases in which I have justified using multiple inheritance, virtual inheritance, private inheritance, and templates.