#include - brackets against quotes in Xcode?

Question

In MSVC ++ #include files are searched differently depending on whether the file is enclosed in "" or <>. The cited form is executed first in the local folder, and then in the / I specified locations. The shape of the angle bracket allows you to avoid the local folder.

This means that in MSVC ++ it is possible to have header files with the same name as the runtime and SDK headers.

So, for example, I need to complete the windows sdk windows.h file to identify a macro that causes problems. With MSVS, I can simply add the (optional) windows.h file to my project, as long as I include it using the quote form: -

// some .cpp file #include "windows.h" // will include my local windows.h file 

And in my windows.h I can pull the real one using the brace form:

 // my windows.h #include <windows.h> // will load the real one #undef ConflictingSymbol 

Trying this trick with GCC in Xcode failed. the angle bracket # includes in the system header files to actually find my header files with similar names in my local folder structure. The MSVC system means that it is safe to have the header file “String.h” in my own struct structure. On Xcode, this does not seem to matter.

Is there a way to control the behavior of this search path in Xcode to be more like MSVC? Or I just need to avoid mentioning any of my headers anything that could conflict with the system header. Writing cross-platform code and using multiple frameworks means that the probability of random conflicts seems high.

Answer 1

You should be able to do the same with gcc (I don't know how much xcode wraps things and prevents access to some functions). There are many options that control the search path (see http://gcc.gnu.org/onlinedocs/gcc-4.5.0/cpp/Search-Path.html and http://gcc.gnu.org/onlinedocs/gcc- 4.5.0 / cpp / Invocation.html and find -iquote ). Calling gcc with -v will give you a path that determines where the two differ.

Answer 2

You can try #include "./windows.h" . The compiler must be smart enough to allow this in the local directory.

Answer 3

I am not sure if I understood your question correctly.

Avoiding name problems is always better. "<>" is more dependent on the compiler, while "" "(lol) is more project specific.

for example, when your compiler searches in your compiler folders (system), and when using "windows.h" it will look in your project folder

if enabling windows.h does not work, check your makefile or projectsettings

Answer 4

Note that gcc supports -iquote and -isystem in addition to -I , to give you more control over which directories #includes will look for.