can I use __FILE__ ,__LINE__ etc. in a code witout DEBUG defined?

[baumann.Pan]

where are these macros defined? can I use it a release ver code?

 

[Minti]

What exactly is your question? You can use __FILE__ and __LINE__ in
both DEBUG and NON_DEBUG versions. Or was it something else that you
wanted to ask?

 

[Keith Thompson]

where are these macros defined? can I use it a release ver code?

Please include your complete question in the body of your article; not
all newsreaders show the subject in a useful manner.

The question was:

can I use __FILE__ ,__LINE__ etc. in a code witout DEBUG defined?

And the answer is yes. __FILE__ and __LINE__ (along with several
others) are predefined macros, unconditionally defined by the
preprocessor.

There's nothing called "DEBUG" in standard C (though you can define
something by that name for yourself). (You might be thinking of
NDEBUG, a macro that can be defined to cause the assert() macro to
become a no-op.)

 

[leon]

A good practise is not to use __FILE__ in production code, as compiler
converts __FILE__ into const strings, which takes up static memory.

 

[Walter Roberson]

:A good practise is not to use __FILE__ in production code, as compiler
:converts __FILE__ into const strings, which takes up static memory.

??

Static memory is going to take no more space than dynamic memory, since
malloc() returns a pointer that is worst-case aligned (but you could
calloc() for a less-aligned result.)

malloc() and friends are going to have the overhead of keeping track of
the size and location of the allocated chunk, which is going to take
more space than just storing the string.

The code to compute __FILE__ on the fly is surely going to take more
space than the constant string; I'm not sure how you would even write
such code except by mousing into the debugging symbols for the
executable, which would be pretty non-portable and would very likely
take more space than the constant string would.

The only thing I can see is that if the string were dynamic then you
could reclaim the space once you have determined you do not need it...
but figuring out for sure that you will no longer even indirectly or
through a function pointer call anything from a particular file is
going to require non-trivial embedded logic that would surely be messy
and take more space than was saved.

Perhaps you could expand on your point?

 

[Keith Thompson]

A good practise is not to use __FILE__ in production code, as compiler
converts __FILE__ into const strings, which takes up static memory.

Of course it's going to take up memory. That's what memory is for.

If you need the value of __FILE__, use it. There's probably no way to
get the same information that's going to consume less memory.

Whether you want to use it in production code depends entirely on how
you want production code to behave. __FILE__ and __LINE__ are
typically used in error messages like "Something bad happened on line
42 of foobar.c". If you don't want your production code producing
messages like that, don't use __FILE__ and __LINE__ (you can use #if
or #ifdef to eliminate the code that uses it) -- but keep in mind that
there's a risk in building production and non-production code
differently.