#include with "" or <>

[Sebastian Faust]

Hi,

I hava a somehow strange problem. I hope I am not wrong in this group;
if this is the case please let me know.

I am trying to compile a rather simple C program. As long as I use:
#include <extp.h>
gcc tells me that he cannot find extp.h.
As soon as I write
#include "extp.h"
the compiling continues. Unfortunately, in extp.h there are again
#includes that use <> so I get a similar error later on during the
compiling process. Probably it is a problem with the environment
variables or paths.

Thanks for your help!
Sebastian

 

[Richard Heathfield]

Sebastian Faust said:

Hi,

I hava a somehow strange problem. I hope I am not wrong in this group;
if this is the case please let me know.

I am trying to compile a rather simple C program. As long as I use:
#include <extp.h>
gcc tells me that he cannot find extp.h.
As soon as I write
#include "extp.h"
the compiling continues.

Use the "myheader.h" form for headers you create yourself. For standard
headers and any headers supplied by the implementation, use the

Unfortunately, in extp.h there are again
#includes that use <> so I get a similar error later on during the
compiling process.

If those are standard headers, you have a problem. Otherwise, see above.

Probably it is a problem with the environment variables or paths.

If so, ask in a gcc group.

 

[Thomas Dickey]

If so, ask in a gcc group.

actually almost any newsgroup where people develop with C.
This is not one of those groups.

 

[Laurent Deniau]

Hi,

I hava a somehow strange problem. I hope I am not wrong in this group;
if this is the case please let me know.

I am trying to compile a rather simple C program. As long as I use:
#include <extp.h>
gcc tells me that he cannot find extp.h.
As soon as I write
#include "extp.h"
the compiling continues. Unfortunately, in extp.h there are again
#includes that use <> so I get a similar error later on during the
compiling process. Probably it is a problem with the environment
variables or paths.

add the option -I. to your compiler command line invocation.

a+, ld.

 

[Bart van Ingen Schenau]

Hi,

I hava a somehow strange problem. I hope I am not wrong in this group;
if this is the case please let me know.

I am trying to compile a rather simple C program. As long as I use:
#include <extp.h>
gcc tells me that he cannot find extp.h.
As soon as I write
#include "extp.h"
the compiling continues. Unfortunately, in extp.h there are again
#includes that use <> so I get a similar error later on during the
compiling process. Probably it is a problem with the environment
variables or paths.

More likely, it is a problem with not understanding the difference
between #include <x> and #include "x".

The #include <x> form is meant for system headers, so the compiler will
only look in those places where it knows that system headers are
stored.
The #include "x" form, on the other hand, is meant for user headers.
With this form, the compiler will first look in the current directory.
If the header can not be found there, the search continues as if the
form #include <x> was used.

If the extp.h file is part of the current project, then you should
rewrite the header to use the #include "x" notation for non-system
headers (and for including the file itself in the source code).

If the extp.h file belongs to an external library, then you could tell
the compiler to add the directory where it resides to the search path
for system headers. How to do this is compiler dependent and should be
documented in the compiler documentation/help-file.

Thanks for your help!
Sebastian

Bart v Ingen Schenau

 

[Richard Heathfield]

Thomas Dickey said:

actually almost any newsgroup where people develop with C.

No, if his implementation is misconfigured, the best group in which to
seek help is one which discusses his implementation.

This is not one of those groups.

Your cynicism is misplaced.

 

[Thomas Dickey]

Thomas Dickey said:

No, if his implementation is misconfigured, the best group in which to
seek help is one which discusses his implementation.

Since you didn't bother to even obliquely reference the C standard which
points out

A preprocessing directive of the form

# include "q-char-sequence" new-line

causes the replacement of that directive by the entire contents of the
source file identified by the specified sequence between the "
delimiters. The named source file is searched for in an
implementation-defined manner. If this search is not supported, or if
the search fails, the directive is reprocessed as if it read

your comment was non-responsive. If you'd made the same comment in
comp.unix.programmer, it would have been just as non-responsive (for
different reasons of course ;-)

Your cynicism is misplaced.

As long as you make responses such as you did, then it's a valid comment.

 

[Richard Heathfield]

Thomas Dickey said:

Since you didn't bother to even obliquely reference the C standard
which points out

I suggest you read my reply again, this time paying attention to the
actual words. I refer you particularly to the paragraph in which I
said:

"Use the "myheader.h" form for headers you create yourself. For standard
headers and any headers supplied by the implementation, use the
<implementationsuppliedheader.h> form instead."

and which you unaccountably appear to have missed.

 

[Thomas Dickey]

Thomas Dickey said:

I suggest you read my reply again, this time paying attention to the
actual words. I refer you particularly to the paragraph in which I
said:

"Use the "myheader.h" form for headers you create yourself. For standard
headers and any headers supplied by the implementation, use the
<implementationsuppliedheader.h> form instead."

and which you unaccountably appear to have missed.

no - I read it (otherwise there's no point in a followup).
You mention the two varieties (which are in OP's comment).

But the advice given needs qualification to be useful (there's no mention
that generally compiler options are needed to make it work properly).

Furthermore, it's flawed (that implementation-specific area covers several
pitfalls). My experience is that the best practice is to use quoted
includes only for cases where nested inclusion is not used, for instance.
Otherwise different implementations produce different results for the
search path (all of course disclaimed in the standard as implementation
specific behavior).

btw - this comment:

No, if his implementation is misconfigured, the best group in which to
seek help is one which discusses his implementation.

could be taken to imply that he might want to reinstall his compiler
by suggesting there's something amiss with the configuration.

and this comment;

If so, ask in a gcc group.

can be interpreted as suggesting that OP follow up on gnu.gcc.bug
or gnu.gcc.help (thinking about it, I guess you did mean for OP to
spend time reinstalling the compiler ;-)

 

[Richard Heathfield]

Thomas Dickey said:

no - I read it (otherwise there's no point in a followup).
You mention the two varieties (which are in OP's comment).

But the advice given needs qualification to be useful

Then feel free to qualify it, by all means - that's a great reason for a
follow-up - but please don't pretend I didn't write it in the first
place.

 

[Joe Wright]

no - I read it (otherwise there's no point in a followup).
You mention the two varieties (which are in OP's comment).

But the advice given needs qualification to be useful (there's no mention
that generally compiler options are needed to make it work properly).

Furthermore, it's flawed (that implementation-specific area covers several
pitfalls). My experience is that the best practice is to use quoted
includes only for cases where nested inclusion is not used, for instance.
Otherwise different implementations produce different results for the
search path (all of course disclaimed in the standard as implementation
specific behavior).

btw - this comment:


could be taken to imply that he might want to reinstall his compiler
by suggesting there's something amiss with the configuration.

and this comment;


can be interpreted as suggesting that OP follow up on gnu.gcc.bug
or gnu.gcc.help (thinking about it, I guess you did mean for OP to
spend time reinstalling the compiler ;-)

Dickey

What has Heathfield done that offends you so? Lighten up.

There are exactly two directories into which the C implementation will
look for headers, its own "include" directory and the "current"
directory of the compile process.

1.
#include <head.h> /* presumes "include" directory first */

2.
#include "head.h" /* presumes "current" directory first */

The "" or <> tells the implementation where to look first. Not finding
head.h there, it may (or not) look in the other directory.

 

[Keith Thompson]

There are exactly two directories into which the C implementation will
look for headers, its own "include" directory and the "current"
directory of the compile process.

1.
#include <head.h> /* presumes "include" directory first */

2.
#include "head.h" /* presumes "current" directory first */

The "" or <> tells the implementation where to look first. Not finding
head.h there, it may (or not) look in the other directory.

Are you talking about some particular implementation? If so, please
specify which one; if not, your description is inaccurate.

One implementation I just looked at searches 4 different directories;
another searches 6.

#include <head.h>
searches a sequence of implementation-defined places for the named
header.

#include "head.h"
searches for the named file in an implementation-defined manner (it
needn't even search a sequence of places). If that search fails or is
not supported, it then proceeds as if the directive were #include
<head.h>.

Suppose that, for a particular implementation, the search for <head.h>
starts in a single "include" directory, and the search for "head.h"
starts in the "current" directory. Given
#include <head.h>
if head.h isn't found in the "include" directory, then the directive
fails; the compiler will *not* look in the "current" directory. On
the other hand, given
#include "head.h"
if head.h isn't found in the "current" directory, then the compiler
*will* look in the "include" directory.

 

[Thomas Dickey]

....

Are you talking about some particular implementation? If so, please
specify which one; if not, your description is inaccurate.

....to finish, the C standard does not even mention directories
(though it refers to files without given much context for the concept).
Some implementations do not store header files in a directory.

While it is possible that there are implementations that do not
allow the developer to specify locations for non "system" files
to use bracketed-includes, it seems that those are fairly rare...

 

[David Wade]

...to finish, the C standard does not even mention directories
(though it refers to files without given much context for the concept).
Some implementations do not store header files in a directory.

Several of the IBM Mainframe (S/370, S/390, zSeries) C compilers have
library files in which several headers can be stored. In fact in VM/CMS
directories are not generally used, and are not available on many of the
"disk types"...

While it is possible that there are implementations that do not
allow the developer to specify locations for non "system" files
to use bracketed-includes, it seems that those are fairly rare...

I haven't met one yet, but then I don't use a huge range of compilers...