By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,192 Members | 1,727 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,192 IT Pros & Developers. It's quick & easy.

#include with "" or <>

P: n/a
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

May 11 '07 #1
Share this Question
Share on Google+
13 Replies


P: n/a
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
<implementationsuppliedheader.hform instead.
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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
May 11 '07 #2

P: n/a
Richard Heathfield <rj*@see.sig.invalidwrote:
If so, ask in a gcc group.
actually almost any newsgroup where people develop with C.
This is not one of those groups.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
May 11 '07 #3

P: n/a
Sebastian Faust wrote:
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.
May 11 '07 #4

P: n/a
Sebastian Faust wrote:
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 <xand #include "x".

The #include <xform 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 <xwas 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
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/
May 11 '07 #5

P: n/a
Thomas Dickey said:
Richard Heathfield <rj*@see.sig.invalidwrote:
>If so, ask in a gcc group.

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
May 11 '07 #6

P: n/a
Richard Heathfield <rj*@see.sig.invalidwrote:
Thomas Dickey said:
>Richard Heathfield <rj*@see.sig.invalidwrote:
>>If so, ask in a gcc group.

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.
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 ;-)
>This is not one of those groups.
Your cynicism is misplaced.
As long as you make responses such as you did, then it's a valid comment.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
May 12 '07 #7

P: n/a
Thomas Dickey said:
Richard Heathfield <rj*@see.sig.invalidwrote:
>Thomas Dickey said:
>>Richard Heathfield <rj*@see.sig.invalidwrote:

If so, ask in a gcc group.

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.

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.hform instead."

and which you unaccountably appear to have missed.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
May 12 '07 #8

P: n/a
Richard Heathfield <rj*@see.sig.invalidwrote:
Thomas Dickey said:
>Richard Heathfield <rj*@see.sig.invalidwrote:
>>Thomas Dickey said:
>>>Richard Heathfield <rj*@see.sig.invalidwrote:

If so, ask in a gcc group.

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.

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.hform 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 ;-)

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
May 12 '07 #9

P: n/a
Thomas Dickey said:
Richard Heathfield <rj*@see.sig.invalidwrote:
>Thomas Dickey said:
<snip>
>>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.hform 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
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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
May 12 '07 #10

P: n/a
Thomas Dickey wrote:
Richard Heathfield <rj*@see.sig.invalidwrote:
>Thomas Dickey said:
>>Richard Heathfield <rj*@see.sig.invalidwrote:
Thomas Dickey said:
Richard Heathfield <rj*@see.sig.invalidwrote:
>
>If so, ask in a gcc group.
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.
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.hform 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 ;-)
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.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
May 12 '07 #11

P: n/a
Joe Wright <jo********@comcast.netwrites:
[...]
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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
May 12 '07 #12

P: n/a
Keith Thompson <ks***@mib.orgwrote:
Joe Wright <jo********@comcast.netwrites:
[...]
>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.
....
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...

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
May 13 '07 #13

P: n/a

"Thomas Dickey" <di****@saltmine.radix.netwrote in message
news:13*************@corp.supernews.com...
Keith Thompson <ks***@mib.orgwrote:
Joe Wright <jo********@comcast.netwrites:
[...]
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.
...
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.
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...
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

May 14 '07 #14

This discussion thread is closed

Replies have been disabled for this discussion.