I have lots of serial debug statements litered throughout my project using iprintf(); I would like an easy way to disable these before releasing code in order to improve performance. I also use serial ports in my application, so I really just want to kill the ones using iprintf that are for debug.
Anyone have an elegant way of doing this? (short of a thousand #ifdef statements...)
Turning off Serial Debug statements
Re: Turning off Serial Debug statements
what we do is similar to what the NB libs do, replace the debug
iprintf in our code with one of these, or similar, macros
DWORD DEB_DevOnly; // set to appropriate value
#define DEV_IPRINTF if (DEB_DevOnly) iprintf
in some places we are a little more specific and use
#define DEV_IPRINTFLG(x) if (DEB_DevOnly & (x)) iprintf
just be careful of nesting.
iprintf in our code with one of these, or similar, macros
DWORD DEB_DevOnly; // set to appropriate value
#define DEV_IPRINTF if (DEB_DevOnly) iprintf
in some places we are a little more specific and use
#define DEV_IPRINTFLG(x) if (DEB_DevOnly & (x)) iprintf
just be careful of nesting.
Re: Turning off Serial Debug statements
I find it extremely valuable to have a static Debug class in my standard library that I include in all projects. Then instead of ever using a printf (or in my case std::cout) I just call one of a few methods in that class like Write() or WriteVar(). The class has an enum setting that sets the level of messages I want to see. It has values like None, Taciturn, Verbose etc..
All methods (Write and WriteVar in this case) that can write debug messages take this enum as an optional parameter (it defaults to Taciturn). If you send a message with NONE it will always be shown. If you send one with Verbose but the level is set to Taciturn or None it won't show. Now this isn't as efficient as if 'def ing but in practice I have found it can really help to leave all this in the production code. I provide a way to send a command to the instrument that changes the debug level so that if a unit in the field is having a problem I can just put it in verbose mode and that usually gets me all the information I need. My theory is if you needed a message printed out during development, you might need it again and if you have the memory and CPU why not leave them in your production code but just disable them?
If you really wanted to get rid of the messages using this approach you could just define Write() in the .h so that it becomes inline and then make it do nothing. The compiler will most likely optimize the entire thing away so it would be just like ifdef without all the syntactic ugliness.
One other advantage is your debug code does not really differ from your release code. This has paid benefits when I've had timing problems. Something may work (or not work) because of the time it takes to put a message out the serial port. I can always test if this is the case by just setting the debug level. If you've if def'd everything out you have to reload the debug version.
All methods (Write and WriteVar in this case) that can write debug messages take this enum as an optional parameter (it defaults to Taciturn). If you send a message with NONE it will always be shown. If you send one with Verbose but the level is set to Taciturn or None it won't show. Now this isn't as efficient as if 'def ing but in practice I have found it can really help to leave all this in the production code. I provide a way to send a command to the instrument that changes the debug level so that if a unit in the field is having a problem I can just put it in verbose mode and that usually gets me all the information I need. My theory is if you needed a message printed out during development, you might need it again and if you have the memory and CPU why not leave them in your production code but just disable them?
If you really wanted to get rid of the messages using this approach you could just define Write() in the .h so that it becomes inline and then make it do nothing. The compiler will most likely optimize the entire thing away so it would be just like ifdef without all the syntactic ugliness.
One other advantage is your debug code does not really differ from your release code. This has paid benefits when I've had timing problems. Something may work (or not work) because of the time it takes to put a message out the serial port. I can always test if this is the case by just setting the debug level. If you've if def'd everything out you have to reload the debug version.