# Macro __FILE__ under VC .

This topic is 4227 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hello guys, i got a little problem . I use the macro __FILE__ , with vc 2003 , and i build either in debug or in release . In release, it's fine, i got my string "./xxx.cpp", but in debug i got the FULL path, like "c://....//..//xxx.cpp" , i want to have ONLY the short relativ path . I heard i can have the full path with the command line /FC , but i want the oposite, i want the short path ...or i want to remove the /FC thing, but i dont find it ... Any ideas ?.

##### Share on other sites
It is relatively simply to chop the "long" string into the "short" string at runtime before you print the string. As far as I know, that is your best (maybe only) option.

##### Share on other sites
I'm quite sure if taht it's only a compiler choice to set full path in debug, i may find how to disaable this ... and the problem whith cutting it is that it would require some macro related to VC ...kinda "hack" to me ...

##### Share on other sites
I don't have time to verify this on MSDN [hint hint], but if /FC is the switch to enable the long printing, try /FC-.

CM

##### Share on other sites
Oh, it's definately a "compiler's choice" kind of thing. The macro is standard but its exactly implemention is not. I meant, however, that you could trim the filename from within whatever function you are passing the macro to. For example, if you have an assert macro:

#define MY_ASSERT(c) if(!(c)) { CallAssertHandler(__FILE__); }void CallAssertHandler(const char *file){const char *p = file;const char *f = file;      while(*p != 0)    {      if(*p == '\\' || *p == '/')        f = ++p;         else        ++p;    }    // Use f...}

(Code written quickly just now, may contain bugs, use at your own risk, void where prohibited, et cetera).

##### Share on other sites
Yup i know i can extract the string inside my function, but i want to avoid that, and keep the code clean and portable .

For Msdn, i already looked there :

http://msdn2.microsoft.com/en-us/library/027c4t2s.aspx

But i can't find the c++/advanced/use full path or something they are naming O_o

And the /FC - just set a warning saying taht the "-" is ignored :/

##### Share on other sites
Is this really a problem? Nobody but you and the other developers or testers (if any) will ever see the debug build, right?

##### Share on other sites
Right, but i want this to be portable, so it must compile smoothly under other compiler than VS, moreover, the xml file isnt displayed under I.E, it seems not to like the full path for a reason i dont get now .

And i'm 95% sure this can be solved by setting my compiler properly .

##### Share on other sites
Quote:
 Original post by Ey-LordRight, but i want this to be portable, so it must compile smoothly under other compiler than VS...

Right well I think you may have to use the preprocesser and see if _MSC_VER is defined and work on from there. What you are asking for is platform specific; as mentioned earlier "The macro is standard but its exactly implemention is not"

##### Share on other sites
Yup i may gop that way , even if i odont like it much .

Another thing i noticed, under FireFox, my XMl document ( turned in html with an xsl doc ) is displayed as it should be [ reminder : it bugs under IE ] when the fullpath is set ... i dunno why it doesnt work on I.E, the only change from fullpath vs short path is the name of the file ... those input are giving an error msg under I.E :

<File>c:\documents and settings\propriétaire\bureau\ey-lord\ey-lord.cpp</File>

But this, is ok [short path in release mode ]

<File>.\ey-lord.cpp</File>

the error message [ translate from french by me ... ]

An incorrect text caracter has been found in a text container. Error when trying to work on the ressource
file:///C:/Documents and...

<File>c:\documents and settings\propri

Maybe the tag name File is not allowed in html/xml ... i'll check on that .

##### Share on other sites
It sees the accented e as an invalid character, you're going to have to set your XML character encoding so it will recognize it. FF probably just has a different default encoding than IE.

That's why the full path doesn't work, there's the accented e that your short path doesn't have.

Why can't you find "Configuration Properties"->"C/C++"->"Advanced"->"Use Full Paths"? It's entirely obvious on my compiler. Configuration Properties is the second option (below Common Properties), C/C++ is the third under Configuration Properties (assuming you have a .cpp file in your project somewhere), Advanced is second to last--right above Command Line, then Use Full Paths is third to last--above Omit Default Library Names which is above Error Reporting.
If on, it adds /FC to the command line, if off it does not. There's no way to remove /FC if it's already added so you'll just have to find it and turn it off.

##### Share on other sites
hehe i just figured taht out when i saw taht in FireFox the "e" was dispolayed with a "?" ... thanx anyway for your answer :) ... i think i'll just let the fullpath , it messed a bit with the layout of my output, but really not a big deal .

Problem solved, thx .

##### Share on other sites
Do it in the function. It is, in fact, the only way to ensure portability of your code (as I said, the macro is standard but the exact textual results of the macro is implementation-defined). If one compiler provides a switch to control the behavior of the macro, that doesn't mean another will, and that doesn't mean you'll have other people using the same compiler actually pass the appropriate switch (and, for what it is worth, in all my years of using Microsoft's compiler I've never come across a switch to always force the short name, though I haven't looked that hard). You can't expect portability when you are using a feature whose exact implementation is inherently non-portable; your only solution is to execute code to force each potential implementation to appear the same -- thus, a loop like I mentioned (which would need to be extended to support portability to, say, Classic Mac OS which used ":" as a path delimiter -- just for the record).

The only other thing I can suggest -- which still is not a solution that provides anything like portability -- is to alter the compiler options so that NDEBUG is defined, even in the "Debug" configuration. This may break or confuse other debug/release logic you or your external libraries may be using, but it might be the thing that determines if the preprocessor emits the full or short path when expanding __FILE__.

##### Share on other sites
Most 3rd party libs I've seen just do it in the function, as jpetrie suggests. Even my own memory manager does that.

From my code:
static const char* StripPath(const char* psz){   const char* p = strrchr(psz, '\\');   if(!p)   {      p = strrchr(psz, '/');      if(!p) return psz;   }   return p+1;}// In a function (szFile is the __FILE__ passed to it):m_theCaller.szFile = StripPath(szFile);

• 45
• 11
• 17
• 11
• 13