Determining path for ambiguos include

[messenjah]

I have code which I compile with no problems with gcc/g++ and has a local string.h file. So if I have a source file that has #include <string.h> there is scope for confusion whether this means the local string.h or the standard one. The way the code is structured is that this means the standard string.h. If the local string.h is required then the include is achieved by #include "string.h" . This behaviour is achieved with gcc by passing a -I- switch to the compiler. That is to say #include <string.h> refers to the standard string.h while #include "string.h" refers to the local one.

Now I am trying to compile the same code with MS Visual Studio 2005. Is there an equivalent to the -I- switch? I know I can simply rename the file but that means changing all other files that include the local string.h as well and I am just not ready to do that just now.

[greg022549]

If I am understanding you correctly. You have created a header file and you want to use in a .cpp file? If so, you need to use #include "string.h" not <string.h>

[messenjah]

Correct. If I do #include "string.h" I get the local string.h. However if I want the standard string.h and I do #include <string.h> I still get the local string.h i.e. it masks the standard string.h

[Zhuge]

Hmm, that's interesting. I just did a test using your example in MSVC 2008, and using <>s always included the library file. Perhaps the local directory is listed as one of the <> include directories for some reason?

[messenjah]

You're right. I forgot to mention that I was passing the local directory as an include search path using the /I switch. It was therefore overriding the library include path in looking for string.h. With gcc/g++ the -I- switch tells it to look for all <> include files within the library include path and ignore those paths specified by -I.

The whole thing was just too annoying so I just renamed the local file and everything is now honky-dory.

Thanks.