Search for built-in header and application header

[linq936]

Hi,
I always have an impression that for the following semantics:
#include <something> e.g. #include <stdio.h>
Compiler searches it from built-in header search path, on UNIX, it
could be /usr/include, /bin/include.

And for the following semantics:
#include "someting" e.g. #include "mine.h"
Compiler searches it according to the -I command option and the
built-in search path.

But I just encountered a problem, it is Visual C++ compiler, it
seems for #include <> type, it also search for -I path. And it
automatically add "include" to the end of -I path, here is an example:

I have -I c:/repo in VC compiler path and in my C code, I have:
#include <auto_array> while the file actually locates at c:/repo/
include/auto_array, but VC compiler finds it.

Could you confirm 2 things:

1. Compiler searches builtin path and -I command option for both
"#include <>" and "#include "" " type include.

2. Compiler add "include" to the end of each search path named in -I
option.

Here is copy & paste from my compile command:

c:/msvsn2003/vc7/bin/cl.exe -W3 -Tp ../s/TestUtils.c -c -nologo -GR -
MDd -Ob2 -Zi -GX -DDEBUG -DNT -DNO_TCL_STUBS -FdlibTestUtils.pdb -
FplibTestUtils.pch -Ic:/repo -I../i
TestUtils.c

Thanks.

 

[Keith Thompson]

I always have an impression that for the following semantics:
#include <something> e.g. #include <stdio.h>
Compiler searches it from built-in header search path, on UNIX, it
could be /usr/include, /bin/include.

And for the following semantics:
#include "someting" e.g. #include "mine.h"
Compiler searches it according to the -I command option and the
built-in search path.

But I just encountered a problem, it is Visual C++ compiler,

[snip]

For '#include <foo.h>', the compiler "searches a sequence of
implementation-defined places" for the foo.h header. (Note that a
header needn't be a source file; for example, some compilers support
precompiled headers.)

For '#include "foo.h"', the compiler searches for a source file" in an
implementation-defined manner". If that search fails, it tries again
as if the argument were '<foo.h>'.

See C99 6.10.2 for the full statement of the rules. See
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf> for the
latest post-C99 draft (that section is identical in the actual C99
standard and in n1124).

I believe the behavior you describe is consistent with the (fairly
loose) requirements of the standard.

If you have questions about the behavior of the Visual C++ compiler,
you'll need to ask in a forum that discusses the Visual C++ compiler,
rather than just the C language.

 

[cr88192]

Hi,
I always have an impression that for the following semantics:
#include <something> e.g. #include <stdio.h>
Compiler searches it from built-in header search path, on UNIX, it
could be /usr/include, /bin/include.

And for the following semantics:
#include "someting" e.g. #include "mine.h"
Compiler searches it according to the -I command option and the
built-in search path.

exact details depend, but:
usually '<...>' searches the both the user and system specified include
directories;
usually "..." first searches in the path of the source file, maybe then
behaving like '<...>'.

 

[Barry Schwarz]

On Wed, 22 Aug 2007 11:00:27 -0700, (e-mail address removed) wrote:


snip

But I just encountered a problem, it is Visual C++ compiler, it
seems for #include <> type, it also search for -I path. And it
automatically add "include" to the end of -I path, here is an example:

snip

Since your question has nothing to do with the language and everything
to do with your particular compiler, you will get better answers from
the microsoft.public.vc family of newsgroups.


Remove del for email