Debug version - Release version 
Author Message
 Debug version - Release version

During development I'm using some debug functions to add lines
to a log file. In the release version I don't want these
functions and data in the final target (to save some memory).

What I did:

#ifdef DEBUGVERSION
    db ( "this line is added to the logfile" );
#endif

I compile the debug version with the identifier DEBUGVERSION
defined.

Now I want to get rid of the #ifdef - #endif clause, to make
the sourcecode better readable.

All suggestions are welcome,

regards,


(Microsoft C 6.00A / Visual C 1.5)



Fri, 25 Jun 1999 03:00:00 GMT  
 Debug version - Release version

Quote:

> [snip]

> #ifdef DEBUGVERSION
>     db ( "this line is added to the logfile" );
> #endif

> [snip]

> Now I want to get rid of the #ifdef - #endif clause, to make
> the sourcecode better readable.

> All suggestions are welcome,

> regards,


> (Microsoft C 6.00A / Visual C 1.5)

You could put the #ifdef - #endif inside db().
The function call would always be there; but
the function itself wouldn't actually do anything
unless DEBUGVERSION is #defined.  (This could
give you an efficiency problem if there are
db() calls inside loops in critical sections
of code.  You'll have to profile the code to
know for sure.)

Another point unrelated to your question:
you might want to consider making db() a
printf()-type function
so that you can stick values of variables
in the string that you write to the log file:

#include <stdarg.h>

int db(const char *format, ...)
{
#ifdef DEBUGVERSION

    va_list argp;
    FILE *debug_fp;
    int char_count = 0;

    debug_fp = fopen(DEBUG_FILENAME, "w");
    if (debug_fp != NULL)
    {
        va_start(argp, format);
        char_count = vsprintf(debug_fp, format, argp);
        va_end(argp);
        fclose(debug_fp);
    }
    return char_count;
#else
    return 0;
#endif

Quote:
}

--Bill


Sun, 27 Jun 1999 03:00:00 GMT  
 Debug version - Release version

Quote:

>During development I'm using some debug functions to add lines
>to a log file. In the release version I don't want these
>functions and data in the final target (to save some memory).
>What I did:
>#ifdef DEBUGVERSION
>    db ( "this line is added to the logfile" );
>#endif
>I compile the debug version with the identifier DEBUGVERSION
>defined.
>Now I want to get rid of the #ifdef - #endif clause, to make
>the sourcecode better readable.
>All suggestions are welcome,

Have a look at your implementors solution for assert(), a macro
that does not have any effects if _NDEBUG is defined. You might
get some nice ideas from that example.

Kurt

--
| Kurt Watzka                             Phone : +49-89-2180-6254



Sun, 27 Jun 1999 03:00:00 GMT  
 Debug version - Release version

Assuming you still want to log during development and testing phases, you
could have a macro definition at the top of your file or in an include
which defines a debug macro.  For example:

#ifdef DEBUGVERSION /* Or a call to your specific function or ... */
#define DB( x ) fprintf( debug_output_stream, "%s", ( x ) );
#else
#define DB( x )
#endif

Then, in your code:
   DB( "this line is added to the logfile" );

Personally, I would use a longer macro name, like
LOG_DEBUG_STRING( x )
but that is a matter of taste.  I am not sure if this accomplishes what you
want, or even if it is better than surrounding the output statement with
#ifdef/#endif.  The debug functions will not be linked into the final
release, unless they are referenced somewhere in either case.  I actually
like the #ifdef/#endif in the code body better (personally) since it makes
it clear what is intended.  If the macro is descriptive enough, then there
is not much difference.



Quote:
> During development I'm using some debug functions to add lines
> to a log file. In the release version I don't want these
> functions and data in the final target (to save some memory).

> What I did:

> #ifdef DEBUGVERSION
>     db ( "this line is added to the logfile" );
> #endif

> I compile the debug version with the identifier DEBUGVERSION
> defined.

> Now I want to get rid of the #ifdef - #endif clause, to make
> the sourcecode better readable.

> All suggestions are welcome,

> regards,


> (Microsoft C 6.00A / Visual C 1.5)



Sun, 27 Jun 1999 03:00:00 GMT  
 Debug version - Release version


Quote:
>During development I'm using some debug functions to add lines
>to a log file. In the release version I don't want these
>functions and data in the final target (to save some memory).

>What I did:

>#ifdef DEBUGVERSION
>    db ( "this line is added to the logfile" );
>#endif

>I compile the debug version with the identifier DEBUGVERSION
>defined.

>Now I want to get rid of the #ifdef - #endif clause, to make
>the sourcecode better readable.

>All suggestions are welcome,

>regards,


>(Microsoft C 6.00A / Visual C 1.5)

It's a lot easier to remove than add them again later, so my first suggestion would
be to leave them in (or at least, any that you feel could useful later), but if you
really want to remove them, it would be a simple task to do a small program to
read each line, and write out all those lines that are not #ifdef DEBUGVERSION,
the associated #endif, and anything between the two.  I use REXX for things
like this, very easy to write and execute.  Attached is a small code section
dealing with the pertinent function.  No attempt to make it overly intelligent,
just a quick and dirty chunk of code to clean out the debug sections.

     don friedel jr.

       (The opinions expressed here are my own. BMC Software, Inc. makes)
       (no representations or promises regarding the reliability,       )
       (completeness, or accuracy of the information provided in this   )
       (discussion; all readers agree not to rely on or take any action )
       (against BMC Software in response to this information.           )

Assume: rfile is input file, wfile is output file

do until (LINES(rfile) = 0)                            
  curline = LINEIN(rfile)                              

  if ( ( SUBWORD(curline,1,1) = '#ifdef' ) &,          
       ( SUBWORD(curline,2,1) = 'DEBUGVERSION' ) ) then
    do until ( SUBWORD(curline,1,1) = '#endif' )        
      curline = LINEIN(rfile)                          
    end                                                
  else do                                              
    chars = LINEOUT(wfile,curline)                      
    if ( chars \= 0 ) then do                          
      say 'Error on writing out"' curline '"'          
      say 'LINEOUT returned' chars                      
      exit 99                                          
    end                                                
  end                                                  

end                                                    
exit 0



Sun, 27 Jun 1999 03:00:00 GMT  
 Debug version - Release version

Quote:

> During development I'm using some debug functions to add lines
> to a log file. In the release version I don't want these
> functions and data in the final target (to save some memory).

> What I did:

> #ifdef DEBUGVERSION
>     db ( "this line is added to the logfile" );
> #endif

> I compile the debug version with the identifier DEBUGVERSION
> defined.

> Now I want to get rid of the #ifdef - #endif clause, to make

[This is being accepted because it answers a completely different question
 than the other ones did, even if the answer is not particularly portable.
 Discussion of the contents should probably migrate to comp.lang.awk. -mod]

Try the following awk script. It is by no means complete, but
should work in most cases.

# Warning: This is *not* tested, it does *not* cover all cases.
#          Specifically, I have not handled the cases where
#          the #ifdef occurs within a comment or a #if 0 block.
# Vivek Chopra. Tue Jan  7 10:07:26 IST 1997

BEGIN { in_debug=0;          # within a #ifdef DEBUGVERION
        in_comment=0;        # within a comment. Not implemented.
        in_if_zero=0;        # within a `#if 0.' Not implemented.
        in_nested_define=0;  # within a #define inside a #ifdef
DEBUGVERSION
      }

{ if ( $0 ~ /^\#ifdef DEBUGVERSION/ )
  {
      # skip
      in_debug++;
  }
  else if ( $0 ~ /^\#if/ )
  {
    if (in_debug == 0)
      print $0
    else
      in_nested_define++;
  }
  else if ( $0 ~ /^\#endif/ )
  {
    if (in_nested_define != 0)
      in_nested_define--;
    else if (in_debug != 0)
      in_debug--;
    else
      print $0;
  }
  else
  {
    if (in_debug == 0)
      print $0
  }

Quote:
}

--
/* Vivek Chopra */
#include <std/disclaimer.h>


Sun, 27 Jun 1999 03:00:00 GMT  
 Debug version - Release version

Quote:

>During development I'm using some debug functions to add lines
>to a log file. In the release version I don't want these
>functions and data in the final target (to save some memory).
>What I did:
>#ifdef DEBUGVERSION
>    db ( "this line is added to the logfile" );
>#endif

What about this:

1. in a header file:

    #ifdef DEBUGVERSION
         #define DB(s)   db(s)
    #else
         #define DB(s)
    #endif

2. to print a message:

    DB( "this line is added to the logfile" );

Best regards,
Wolfgang



Sun, 27 Jun 1999 03:00:00 GMT  
 Debug version - Release version

Quote:

> During development I'm using some debug functions to add lines
> to a log file. In the release version I don't want these
> functions and data in the final target (to save some memory).

> What I did:

> #ifdef DEBUGVERSION
>     db ( "this line is added to the logfile" );
> #endif

> I compile the debug version with the identifier DEBUGVERSION
> defined.

> Now I want to get rid of the #ifdef - #endif clause, to make
> the sourcecode better readable.

You could instead put the ifdef around the definition of db() :

    #ifdef DEBUGVERSION
    void db(char *msg);       /* externally defined */
    #else
    #define db(ignored)       /* defined to be nothing */
    #endif

Now, if you don't define DEBUGVERSION, then the calls to db()
will just disappear.

If db() is variadic, then things are a bit uglier....

Lex



Sun, 27 Jun 1999 03:00:00 GMT  
 Debug version - Release version

Quote:

>What I did:

>#ifdef DEBUGVERSION
>    db ( "this line is added to the logfile" );
>#endif
>Now I want to get rid of the #ifdef - #endif clause, to make
>the sourcecode better readable.
>regards,

>(Microsoft C 6.00A / Visual C 1.5)

Many systems have a utility like unifdef, which allows selective
processing of preprocessor directives.  If you have this utility,

unifdef -UDEBUGVERSION inputfile.c

(for whatever you input is named) will remove the #ifdef - #endif clauses
and write the result to standard output (leaving all other ifdef's, etc.
intact.)

--
Roger Wells (speaking only for myself)



Wed, 30 Jun 1999 03:00:00 GMT  
 Debug version - Release version

Quote:

>You could put the #ifdef - #endif inside db().
>The function call would always be there; but
>the function itself wouldn't actually do anything
>unless DEBUGVERSION is #defined.  (This could
>give you an efficiency problem if there are
>db() calls inside loops in critical sections
>of code.  You'll have to profile the code to
>know for sure.)

A better approach is to eliminate the call altogether
from the distributed version of the code.  Consider this:

db.c:

        #include <stdio.h>
        #include <stdarg.h>
        #include "db.h"

        FILE    *tracefile;

        int
        db (const char *msg, ...) {
                va_list ap;
                va_start (ap, msg);
                if (tracefile)
                        vfprintf (tracefile, msg, ap);
                va_end (ap);
        }

db.h:

        #ifndef DB_H
        #define DB_H

        #ifdef DEBUGVERSION

        #include <stdio.h>
        #include <stdarg.h>
        extern FILE     *tracefile;
        int db (const char *, ...);

        #define DEBUG_TRACE     db

        #else   /* DEBUGVERSION */

        #define DEBUG_TRACE     (void)

        #endif  /* DEBUGVERSION */

        #endif  /* db.h */

Now, in your source file, a line like

        DEBUG_TRACE ("entering whizzsort routine (%d, %d)", foo, bar);

will either call db() in your debug version, or evaluate a comma
expression and discard the result in your distributed code -- something
any decent compiler will eliminate as dead code.  (Unless you pass
an expression with a side effect as an argument, of course, which
may not be a good idea anyway.)  Lots of compilers will still keep
the literal string around, unfortunately.

In big projects I like to define several levels of tracing macros
(TRACE0, TRACE1, TRACE2, etc.) and use an environment variable to
control the amount of debug output.  It's also useful to isolate
tracing to specific subsystems.

-Peter
--



Wed, 30 Jun 1999 03:00:00 GMT  
 Debug version - Release version


Quote:
> Now I want to get rid of the #ifdef - #endif clause, to make
> the sourcecode better readable.

See the C FAQ, questions 10.18 and 18.16.

b



Wed, 30 Jun 1999 03:00:00 GMT  
 Debug version - Release version

: You could put the #ifdef - #endif inside db().
: The function call would always be there; but
: the function itself wouldn't actually do anything
: unless DEBUGVERSION is #defined.  (This could
: give you an efficiency problem if there are
: db() calls inside loops in critical sections

Could it? Shouldn't a decent optimiser remove calls to any
empty function? Or is that not allowed for some reason?

More generally, how much does the Standard constrain the way in
which optimisation may be implemented? Apart from obvious things
like preserving order of evaluation etc., is the implementor
reasonably free to do as much clever stuff as he wants here?

--
//.\\/\\/\\\\//////\//\/\/\/\\\/\\\/\\\\/\//\/\\\//\\\\/\\\//\/\\//\\\/\\//
\        Jason Tyler            "What's so unpleasant about being drunk?" \

///\\/\\/\\\\\\/\\/\/\\/\\\/\//\\///\\\\\///\//\\\\\\\///\/\\\/\/\\\//\\//\



Wed, 30 Jun 1999 03:00:00 GMT  
 Debug version - Release version

Quote:

>     #ifdef DEBUGVERSION
>          #define DB(s)   db(s)
>     #else
>          #define DB(s)
>     #endif

I tend to say

  #ifndef NDEBUG
    #define D(x) x
  #else
    #define D(x)
  #endif

and say things like

  D( printf("i == %i\n", i); )

which seems to work quite well.  The nice thing is that it works for
larger chunks of text too, as long as they contain balanced `(' and `)'
tokens, which they should if they're syntactically expressions or
larger, and as long as there aren't any top-level commas, which isn't
too much of a restriction.
--
[mdw]

`When our backs are against the wall, we shall turn and fight.'
                -- John Major



Wed, 30 Jun 1999 03:00:00 GMT  
 Debug version - Release version

Quote:

> During development I'm using some debug functions to add lines
> to a log file. In the release version I don't want these
> functions and data in the final target (to save some memory).

> What I did:

> #ifdef DEBUGVERSION
>     db ( "this line is added to the logfile" );
> #endif

> I compile the debug version with the identifier DEBUGVERSION
> defined.

> Now I want to get rid of the #ifdef - #endif clause, to make
> the sourcecode better readable.

Well, I waited a day and didn't see this method posted, so
I'll suggest it.  Besides, I'm interested to know of any
potential portability problems with it.

Try this:

/* debug.h */
void debug_output( const char * format, ... );
#if defined DEBUG
  #define DB debug_output
#else
  #define DB 1 ? (void)0 : debug_output
#endif
/* end of debug.h */

Now you can sprinkle printf-like "calls" to DB throughout
the code:

  DB("Error opening %s; status %d", filename, stat);

When debugging, this expands to:

  debug_output("Error opening %s; status %d", filename, stat);

When not debugging, this expands to:

  1 ? (void)0 : debug_output("Error opening %s; status %d", filename, stat);

A good compiler (all but one that I know of) will optimize
out the call to debug_output, leaving nothing.  Ones that
don't will generate a branch (that will always be taken)
around a subroutine call that is never performed.

Then, write debug_output as a printf-type routine:

/* debug.c */
#if !defined DEBUGGING
void debug_output( const char * format, ... ) {}
#else
void debug_output( const char * format, ... )
{
    va_list args;
    char output[256];
    int len;
    va_start(args, format);
    len = _vsnprintf(output, sizeof output, format, args);
    va_end(args);
    output_string(output, len);

Quote:
}

#endif
/* end of debug.c */

Note that when not debugging the do-nothing definition of
debug_output is needed only if the compiler does not
optimize out the calls to it.  Like I said above, only
one compiler I use (of about 5) requires it.

BTW: _vsnprintf is a "safe" version of vsprintf, in that
it allows the caller to specify the length of the output
buffer.  I would recommend using such a beast in any
debugging code.

I'd be interested in hearing any portability concerns with
the non-debugging version of the DB macro above.

[Obviously, vsnprintf is not a feature yet, although it was accepted
 for C9X. -mod]



Wed, 30 Jun 1999 03:00:00 GMT  
 Debug version - Release version

|> >
|> > [snip]
|> >
|> > #ifdef DEBUGVERSION
|> >     db ( "this line is added to the logfile" );
|> > #endif
|> >
|> > [snip]
|> >
|> > Now I want to get rid of the #ifdef - #endif clause, to make
|> > the sourcecode better readable.
|> >
|> > All suggestions are welcome,
|> >
|> > regards,
|> >

|> >
|> > (Microsoft C 6.00A / Visual C 1.5)

Sun machines, and perhaps others, have a utility called "unifdef"
that can remove such code.



Wed, 30 Jun 1999 03:00:00 GMT  
 
 [ 17 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Debug version ok but release version problem

2. Debug Version and Release Version

3. Win32 debug version and Win32 release version

4. Why the Font size is not same between Debug version and Release Version

5. Debug version Ok, Release version Failed

6. Debug version ok but release version problem

7. Debug version works, Release version does not?!

8. Released version programme is larger in size than the debug version one’s

9. the diffrence of the debug version and release version

10. Debug version works, Release version doesn't

11. Debug version crashes but Release version doesnt

12. Debug version program works fine but its release version causes a GP error

 

 
Powered by phpBB® Forum Software