what's the best way to handle the verbose mode of an application ?

[mast2as]

In the same vein as the topic that I started on exception handling ;-)
.... If I have read (not all of them though) the documents that you
guys pointed me to, the try/throw/catch mechanism should really be kept
for exception handling (basically errors whevere they are critical or
not). Now, while I am developing this application, so far I used
std::cout quite a lot to check that the code was doing the right thing
(writing out to the console the content of some variables, etc). Now
that the program becomes more complex and that I need to develop some
over parts of the application, I would like to start removing those
lines. Of course at the same time i am thinking that I may need them
back again one day so commenting them out or deleting them doesn't seem
to be the best option, ... so my question is... What would the best way
to implement some sort of verbose system in a program where for example
the user can specify how 'chatty' he/she wants the output to be (myapp
-verbose 1).
So far what I have been using is the very basic thing like

#define VERBOSE 1

#ifdef VERBOSE
std::cout << "write something out to the console" << std::endl;
#endif

but i know from you guys know that macro are evil ;-), plus this
mechanism doesn't handle the level of verbosity that a user might want
to set (0 silent, 1 basic info, 2 every possible message).

Should I just write a simple inline function like printOutInfo and use
it whenever I have something to print out to the console, something
like... (code not tested)

enum VerboseLevel
{
kSilent = 0,
kPrintImportantStuff,
kPrintEverything
};

void printOutInfo( const char* msg, VerboseLevel msgVerboseLevel,
VerboseLevel userVerboseLevel
{
if ( userVerboseLevel != kSilent && userVerboseLevel >=
msgVerboseLevel )
{
std::cout << msg << std::endl;
}
}

int main( int argc, char *argv[] )
{
VerboseLevel userVerboseLevel = (VerboseLevel) atoi( argv[ 1 ] );
printOutInfo( "some very important message", kPrintImportantStuff,
userVerboseLevel );
return 0;
}

Or is there a good way to do that, that someone described already
somewhere ;-)

Many thanks, Mark -

 

[Ian Collins]

In the same vein as the topic that I started on exception handling ;-)
... If I have read (not all of them though) the documents that you
guys pointed me to, the try/throw/catch mechanism should really be kept
for exception handling (basically errors whevere they are critical or
not). Now, while I am developing this application, so far I used
std::cout quite a lot to check that the code was doing the right thing
(writing out to the console the content of some variables, etc). Now
that the program becomes more complex and that I need to develop some
over parts of the application, I would like to start removing those
lines. Of course at the same time i am thinking that I may need them
back again one day so commenting them out or deleting them doesn't seem
to be the best option, ... so my question is... What would the best way
to implement some sort of verbose system in a program where for example
the user can specify how 'chatty' he/she wants the output to be (myapp
-verbose 1).

Save your self a lot of unnecessary grief and learn Test Driven
Development. With proper robust unit tests, incremental development
makes this stuff redundant.

 

[mast2as]

Save your self a lot of unnecessary grief and learn Test Driven
Development. With proper robust unit tests, incremental development
makes this stuff redundant.

Hum sounds like another thing I need to learn ;-)

That's fine for debugging my application I guess (so I am going to read
about Test Driven Development) but let's say i also need to output some
data for the user if he/she wants it (progress report, some average
value about processing times, created files, etc...)

 

[Ian Collins]

Hum sounds like another thing I need to learn ;-)

That's fine for debugging my application I guess (so I am going to read
about Test Driven Development) but let's say i also need to output some
data for the user if he/she wants it (progress report, some average
value about processing times, created files, etc...)

Than that becomes a user story and you do it in the normal way. What the
user wants should not be confused with what the developer wants.