Printable View
Hello guys,
For some debugging info I need __FILE__, but the problem is, it shows also the full pathname. I rather don't want to do some stringmanipulation to cut off only the source name. So is there another way to get the current filename without calling a function (a MACRO is ofcourse much faster)? Maybe a setting to GCC...?
I googled and found someone says in *nix systems __FILE__ shows only the filename, while DOS shows the complete path, I guess he was mistaken.
Oh my god,
this is ridiculous man! Hahahaha, it shows full pathname in debug-mode and just the filename in release mode, can you believe that? The following question rises to me, how can I turn off the full pathname anyway?
"Build the program in release mode, duh!" No really, is there a sneaky switch I need to pass GCC?
Thank you.
On the other hand, it could not take more than 5 minutes to write a function that will use strrchr() to eliminate the path IF there is one.
There are all kinds of scenarios where having to do that just sucks.Quote:
Originally Posted by MK27
If the OP would like to explain what he's using __FILE__ for, maybe we can find some alternate solution, because gcc is just broken in this regard.
:pQuote:
Originally Posted by brewbuck
Considering the task is always identical, you should not have to write such a function more than once in your life. And considering it's about 4 lines, it makes sense no one has bothered to include fullpath2filename() in a standard library as a convenient wrapper for strrchr().
Sounds more like you mean, "There are all kinds of scenarios where having to write code in C just sucks". Maybe.
I'd like to hear what standard says about this. I checked committee draft linked in sticky in C board and some C89 draft but they didn't say what should __FILE__ include. Could someone with a copy of standard tell me what does it says about __FILE__?Quote:
Originally Posted by brewbuck
C99 and C++03 say nothing about __FILE__.Quote:
Originally Posted by fronty
Writing the function isn't what sucks. Having to call it at runtime sucks.Quote:
Originally Posted by MK27
Yes, for such speed critical applications as:Quote:
Originally Posted by brewbuck
May the whole thing could be #ifdef'd in this case.Quote:
Originally Posted by Andaluz
BTW WRT the standard I found this here:
http://gcc.gnu.org/onlinedocs/gcc-3....ed-Macros.html
Quote:
The standard predefined macros are specified by the C and/or C++ language standards, so they are available with all compilers that implement those standards. Older compilers may not provide all of them. Their names all start with double underscores.
__FILE__
This macro expands to the name of the current input file, in the form of a C string constant. This is the path by which the preprocessor opened the file, not the short name specified in #include or as the input file name argument. For example, "/usr/local/include/myheader.h" is a possible expansion of this macro.
*sigh* I was searching for the wrong thing. For readability, the text of C99 inserts a space between consecutive underscores. Anyway, C99 itself only states that it is "the presumed name of the current source file (a character string literal)." Naturally, the format of the name is left unspecified.Quote:
Originally Posted by MK27
It has nothing to do with performance. The reason you have debug messages is for debugging. If you're printing a debug message, something has potentially gone very wrong. In a world where things are wrong, I don't want to call any function that isn't absolutely necessary. I just want to get my debug message into a log file/onto the screen and move on.Quote:
Originally Posted by MK27
It's like the old argument about why the Linux kernel doesn't "dump core" when it panics. The problem is, if the kernel is panicking, how can you be sure that the kernel is in a sane enough state to safely write to disk? Your core dumping routine might end up wiping out the entire FS. Thus, no kernel core dumps (it may have changed since I was involved in that debate, I don't know).
You won't have this issue if you're compiling in the same directory as the source file.
Well, you're the pro, but it seems to me like you are saying "how can I use any code to create debugging output when the code I've already written has bugs in it?"* Maybe that's true, I just see Zeno's arrow in here somehow.Quote:
Originally Posted by brewbuck
Hard also to imagine a situation in which a full pathname is more useless than a relative one.
* going with the core dump analogy, I guess you should just leave that in the quiver. Hard to actually fix the bugs as a developer this way tho...
It's just a personal heuristic.Quote:
Originally Posted by MK27
The problem is that it CHANGES depending whether you're compiling for debug or not. The lack of consistency is the issue.Quote:
Hard also to imagine a situation in which a full pathname is more useless than a relative one.
Wow. . . this is a monumental day. . . laserlight made a mistake.Quote:
Originally Posted by laserlight