I have a 'debug' function placed ate several points on my code.
'My_debug' prints information to a log file:
Ok, I have a 'mydebug.enable' and 'mydebug.disable' methods to let the output or simply return without doing nothing. As you can imagine, inside my function I have If 'i'm enabled' == false return
So, now I have a 'n' calls, that means nx2 useless at every point.
1 2
mydebug<< "some information";
if my debug return
I'd like to have the posibility of disable this, but at run time. In other words, a magic way to comment lines of code at run time. Is it possible ?
Thanks
comments are instructions to the compiler (ie. instructions to ignore whatever comes after //). Your program doesn't "see" them ever. So to answer your question, no you cannot selectively comment out code at runtime. what I usually do is identify the point at which the problem seems to be occuring, and then add an if statement. I don't know if this answers your question, but something along the lines of this:
1 2 3 4 5
for (int i = 0; i != limit; i++) {
//this is the loop that does something I want to log when condition == 1
if (condition == 1) mydebug << useful_debug_output;
//rest of the code here
}
I don't know if this answers your question, you'd need to be more specific.
In real world: We use #ifdef _DEBUG to roll out a binary with minimal or no debugging.
Example: Back in March we had a problem with certain laptops with Broadcom wireless cards: The connection kept dropping at certain sites. After much troubleshooting, it was decided that Broadcom needed to check it out, so we escalated. What they did: They recompiled the driver in debug mode and we collected logs using this debug build.
I am just giving a brief hint of one possible way.
Suppose I have a to write a function foo(), then I write two versions of foo().
(i) foo_with_Log()
(ii) foo_without_Log()
void
print_the_debug_Information() {
// keep printing the debug information
// check if you want to continue printing or not
if ( no_more_print_required) {
f = foo_without_Log;
}
}
main() {
f = foo_with_Log();
// use f every where you want to use foo_with_Log() -- do not call foo_with_Log(), call it using the function pointer.
}
// Further you can create a MACRO to make f look like a function foo...
Then, during the course of the code, I would call the LOG() macro. In the debug build, I would get the logging, while in the Release build I would get the logging stripped away.
mmm.
In my case I have a custom debug-log_messenger that works using the << operator
So I have a lot of lines
my_debug<<"information is "<<a_value;
When the end of function is reached I emit the message (stored at stringstream) to de device I have previous choose (to de IDE debug window, to a custom window, to a log file ).
I have a bool var ' enabled' , so I can easy show or not the info. But in case I dont want view the 'log' data I'm loosing time doing unuseful calls.
In my case I have this create 'my_debug' so : my_debug = new personal_debug();
So I could write my_debug=new ghost_debug(), which has the same functions as my personal_debug(), but without code in it.
I'd have to implement a 'ghost' function, but even in this situation, I have wasting time passing data to nobody....
What I'd want is that my program doesnt spend any milisecond ......
As WEBJOSE said, the best solution colud be to have two versions of the program ? One compiled with theese instructions commented and the other uncommented ?
that reminds me the hidden games in MS Office apps. When you press certain keys, the game would be activated. I think this would be the most premature way to accomplish your goal, but it is simple and it works. Some chain of keys would activate your function. the function just checks a boolean variable, true makes it work. something like that..
No, #define is a preprecessor directive that performs simple text replacement before the compiler is even run.
However, you can have some global variable: int debugLevel;
and: if (debugLevel>=1)debug << "some debug text" << endl;
This is commonly used and has almost no overhead.
However, it gets problematic if you want to omit the if, perhaps because you only have two debug levels "on" and "off" anyway - this would mean moving the debug level check to operator<< of your logger object.
Now, as long as you only have output like: debug << "text " << someIntVariable << " some more text " << someString << endl;
your chances are good that the compiler will transform it to something more or less equivalent to: if (debugEnabled)internalStreamObject << "text " << ... etc
(provided the definition of operator<< is visible for inlining)
This is pretty much what you want. However, when using that approach, you shouldn't output the result of functions with side-effects, because those would be called even with debugging disabled.
Now all debugging code with severity 4 or higher will execute, but severity 3 or lower will not. You can add the specialization globally, or just in a specific file if needs be.
Oh, I didn't read that. Seems like a strange requirement.
The only way I can think of is to template every single function with a bool and call f<true>() if you want debugging and f<false> if you don't. Seems like a right faff for anything even slightly complicated though.
This may be of interest: Logging In C++ : Part 2
http://drdobbs.com/cpp/221900468
Just in case people want a quick summary
Logging is a critical technique for troubleshooting and maintaining software systems. It's simple, provides information without requiring knowledge of programming language, and does not require specialized tools. Logging is a useful means to figure out if an application is actually doing what it is supposed to do. Good logging mechanisms can save long debugging sessions and dramatically increase the maintainability of applications.
This article is a follow-up to Logging in C++. After having used the logging described therein for two years, I needed certain enhancements to it that improve logging granularity by a large margin: Each individual logging statement can be conveniently turned on and off without the need to recompile or even stop and restart the application.
The previous article presented a simple, yet powerful, logging framework in which each log statement has a specific level of detail associated with it. In that framework, the logging detail level depends on how important or interesting the logged information is. When the application runs, a log level is specified for entire application, so only the log statements at or below a specific detail level are enabled and displayed.
If the requirement is to have run time (and not a compile time ) different behavior of the functions with/without logging, then the only way to do it is to call the function through a function pointer, and have two versions of the function(with/without logs). Change the function pointer at run time based on the required condition. I think that is what OP wants.
Also if you are using a shared object, then you can have two versions of the shared objects, and at the run time you can load one with log or without log.
Why not pass a "/Debug" flag at run time? If the argument is passed set some global bool to true and allow the logging functions to run, if not then the bool defaults to false. This is simular to how MS Office applications determine weither or not to run in "safe mode".