From: Matt B. <ma...@be...> - 2004-11-10 08:40:36
|
----- Original Message ----- From: Oliver Morgan <ol...@me...> To: mxf...@li... Subject: [Mxflib-developers] Re: getchar() before exit... Date: Tue, 09 Nov 2004 14:17:58 -0600 >=20 > Fine on making default not getchar(), providing an option can reenable it. >=20 > I was aiming for the following other behaviours consistet across all apps: >=20 > -q quiet: > never writes to stdout > writes errors to stderr > sets exit code on errors and warnings Sounds a good idea. >=20 > (none)default: > writes sparsely to stdout > writes errors warnings and config to stderr > sets exit code on errors and warnings Also sounds a good idea. >=20 > -v verbose: > writes verbosely to stdout > writes errors warnings and config to stderr > sets exit code on errors and warnings Yes, but I would like to go further (but it would take a bit of work to ach= ieve). I would like to have a 64-bit variable that holds a set of debug fl= ags. For example bit 0 set will produce XML-parser debug, bit 1 will produc= e dictionary loader debug, bit 2 will produce smart pointer debug etc... On= e section of bits will be reserved for the application and the rest for the= library. debug messages would change to: debug( DEBUG_SMARTPTR, "Incrementing reference to %d\n", Count ); The verbose flag would be -v (set default set of flags decided by the app) = or -v=3D0x00f0c3070 (set a complex set of debug flags) or maybe even -v=3DS= MARTPTR|DICT|XML (to debug smart pointers, dictionary loading and XML parsi= ng) >=20 > Questions: is the proposed -z orthogonal to this? Or could it be seen as = a "very verbose" (-vv) level? My vote would be for -vv I see -z being orthogonal. There may be times that a pause is required, but= debug isn't. -vv may simply be -v=3D0xffffffffffffffff. Also it seems that some embedded systems may not cope with getchar() at all= (yuck!) so maybe we gain a new function in system.h of the form PauseForIn= put() which will print a prompt and wait - or on embedded systems wait for = some other form of input. >=20 > Another: how does this relate to #ifdef MXFLIB_DEBUG and the mxflib::debu= g() function? The present code seems to imply that debug=20 > messages are only output by mxflib::debug() if both -v and MXFLIB_DEBUG. = Is that what we want? >=20 The idea is that debug messages will only be produced when -v is set, but a= ll debug messages can be removed by not defining MXFLIB_DEBUG. The result i= s that both MXFLIB_DEBUG and -v are required to get debug. Why? Because the= runtime test is done after putting together much of the debug info so even= with -v not supplied most of the CPU cycles are still used. When MXFLIB_DE= BUG is not defined the debug code does not get compiled in. For example: debug("Length of %s is %s\n", Object->Name().c_str(), Int64toString(Objec= t->Size()).c_str()); ...will still build a string version of the 64-bit size and extract buffer = pointers to this and the string containing the object name and passing them= to the debug function which simply discards them. > Should mxflib::debug use vfprintf(stderr, Fmt, args)? > Should mxflib::warning use vfprintf(stderr, Fmt, args)? > Should mxflib::error use vfprintf(stderr, Fmt, args)? >=20 mxflib::debug use vfprintf(STDOUT, Fmt, args) mxflib::warning use vfprintf(stderr, Fmt, args) mxflib::error use vfprintf(stderr, Fmt, args) Two important reasons why debug messages should go to stdout... firstly the= y are not errors, they are debug, but secondly stdout can easily be redirec= ted, stderr can't. Debug produces loads of output and will often need to b= e captured to a file for processing. > thanks > Oliver >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dclick > _______________________________________________ > Mxflib-developers mailing list > Mxf...@li... > https://lists.sourceforge.net/lists/listinfo/mxflib-developers >=20 |