/ Forside / Teknologi / Udvikling / C/C++ / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
C/C++
#NavnPoint
BertelBra.. 2425
pmbruun 695
Master_of.. 501
Bech_bb 500
kyllekylle 500
jdjespers.. 500
gibson 300
scootergr.. 300
molokyle 287
10  strarup 270
forskel på #include <> og #include ""
Fra : Jake


Dato : 27-12-05 12:54

Hejsa

Hvad er forskellen på at skrive

#include <stdio.h>

og

#include "stdio.h"

Sidstnævnte kommando virker ikke når jeg compiler.

Tak på forhånd.....




 
 
Bertel Lund Hansen (27-12-2005)
Kommentar
Fra : Bertel Lund Hansen


Dato : 27-12-05 13:17

Jake skrev:

> Hvad er forskellen på at skrive

> #include <stdio.h>

Den opskrift bruges til systemfiler som ligger i et bestemt
bibliotek.

> og
> #include "stdio.h"

Den kan bruges til vilkårlige filer, men så skal man sørge for at
compileren kan finde den rigtige sti. Hvis man lægger
include-filen i samme mappe som resten af koden, skal der blot
stå filnavnet.

> Sidstnævnte kommando virker ikke når jeg compiler.

Nej, det er klart. Brug de to opskrifter til det de er beregnet
til, altså altid <> til systemfilerne, og "" til dem du selv
laver.

Hvis du nu har nogle hjemmelavede h-filer du gerne vil bruge i
mange projekter, kan du f.eks. lægge dem i en særlig mappe. Hvis
den hedder common_files, kunne en include se sådan ud:

#include "common_files/myownfile.h"

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

Bertel Brander (28-12-2005)
Kommentar
Fra : Bertel Brander


Dato : 28-12-05 14:22

Bertel Lund Hansen wrote:
> Jake skrev:
>
>> Hvad er forskellen på at skrive
>
>> #include <stdio.h>
>
> Den opskrift bruges til systemfiler som ligger i et bestemt
> bibliotek.
>
>> og
>> #include "stdio.h"
>
> Den kan bruges til vilkårlige filer, men så skal man sørge for at
> compileren kan finde den rigtige sti. Hvis man lægger
> include-filen i samme mappe som resten af koden, skal der blot
> stå filnavnet.
>
>> Sidstnævnte kommando virker ikke når jeg compiler.
>
> Nej, det er klart. Brug de to opskrifter til det de er beregnet
> til, altså altid <> til systemfilerne, og "" til dem du selv
> laver.

Det er ikke helt så enkelt.
windows.h, er det en system fil?
Er boost.h fra boost biblioteket en system fil?

Det er almindeligt at bruge "" til filer der ligger i samme
mappe som den der inkluderer den, og <> til filer der
ligger andre steder, og som skal findes vha. path specificeret
til compileren, eller som inkluderes med <stil/header.h>.

/b

Jesper Wolf Jesperse~ (29-12-2005)
Kommentar
Fra : Jesper Wolf Jesperse~


Dato : 29-12-05 23:37

Hej Bertel. Jake et all.

>>> Hvad er forskellen på at skrive
>>
>>> #include <stdio.h>
>>
>>> og
>>> #include "stdio.h"

Faktisk er forskellen at man ved angivelse af "" omkring filnavnet lader
compileren søge i current directory før den leder i include pathen.
Angiver man <> omkring filnavnet er det kun include pathen der bruges.

Hvis man har current directory med først i sin include path er der ingen
forskel mellem de to.

Jeg bruger "" notationen til lokale include filer og <> til systemfiler, den
konvention er der mange der følger.

Med venlig hilsen
Jesper Wolf Jespersen.



Bertel Brander (29-12-2005)
Kommentar
Fra : Bertel Brander


Dato : 29-12-05 23:55

Jesper Wolf Jespersen wrote:
> Jeg bruger "" notationen til lokale include filer og <> til systemfiler, den
> konvention er der mange der følger.

Som jeg skrev er problemet med dette at definere hvad der er
"lokale" og hvad der er "system" filer.

/b

Bertel Lund Hansen (01-01-2006)
Kommentar
Fra : Bertel Lund Hansen


Dato : 01-01-06 20:27

Bertel Brander skrev:

>> Jeg bruger "" notationen til lokale include filer og <> til systemfiler, den
>> konvention er der mange der følger.

> Som jeg skrev er problemet med dette at definere hvad der er
> "lokale" og hvad der er "system" filer.

Det er bare ikke et praktisk problem. Jeg har fulgt den angivne
konvention lige siden jeg begyndte på C, og jeg har aldrig været
i tvivl.

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

Arne Vajhøj (30-12-2005)
Kommentar
Fra : Arne Vajhøj


Dato : 30-12-05 00:22

Jesper Wolf Jespersen wrote:
> Faktisk er forskellen at man ved angivelse af "" omkring filnavnet lader
> compileren søge i current directory før den leder i include pathen.
> Angiver man <> omkring filnavnet er det kun include pathen der bruges.
>
> Hvis man har current directory med først i sin include path er der ingen
> forskel mellem de to.
>
> Jeg bruger "" notationen til lokale include filer og <> til systemfiler, den
> konvention er der mange der følger.

Jeg tror faktisk at den præcise forskel er compiler specifik.

GCC

http://gcc.gnu.org/onlinedocs/gcc-3.2.3/cpp/Search-Path.html

som siger (for en Unix platform):

<> form:

-I dirs
/usr/local/include
/usr/lib/gcc-lib/target/version/include
/usr/target/include
/usr/include

"" form:

dir including file (ikke nødvendigvis current dir)
-I dirs
/usr/local/include
/usr/lib/gcc-lib/target/version/include
/usr/target/include
/usr/include

DEC C for en VMS platform siger (undskyld det lange citat):

For the quoted form, the search order is:

1. One of the following:

o If /NESTED_INCLUDE_DIRECTORY=INCLUDE_FILE (the default) is
in effect, search the directory containing the file in
which the #include directive itself occurred. The meaning
of "directory containing" is: the RMS "resultant string"
obtained when the file in which the #include occurred was
opened, except that the filename and subsequent components
are replaced by the default file type for headers (".H", or
just "." if /ASSUME=NOHEADER_TYPE_DEFAULT is in effect).
The "resultant string" will not have translated any
concealed device logical.

o If /NESTED_INCLUDE_DIRECTORY=PRIMARY_FILE is in effect,
search the default file type for headers using the context
of the primary source file. This means that just the file
type (".H" or ".") is used for the default file-spec but,
in addition, the chain of "related file-specs" used to
maintain the sticky defaults for processing the next
top-level source file is applied when searching for the
include file.

o If /NESTED_INCLUDE_DIRECTORY=NONE is in effect, this entire
step (Step 1) is bypassed.


2. Search the places specified in the /INCLUDE_DIRECTORY
qualifier, if any. A place that can be parsed successfuly as
an OpenVMS file-spec and that does not contain an explicit file
type or version specification is edited to append the default
header file type specification (".H" or ".").

A place containing a "/" character is considered to be a
UNIX-style name. If the name in the #include directive also
contains a "/" character that is not the first character and is
not preceded by a "!" character (that is, it is not an absolute
UNIX-style pathname), then the name in the #include directive
is appended to the named place, separated by a "/" character,
before applying the decc$to_vms pathname translation function.

3. If "DECC$USER_INCLUDE" is defined as a logical name, search
"DECC$USER_INCLUDE:.H", or just "DECC$USER_INCLUDE:." if
/ASSUME=NOHEADER_TYPE_DEFAULT is in effect.

4. If the file is not found, follow the steps for the
angle-bracketed form of inclusion.


For the angle-bracketed form, the search order is:

1. Search the place "/". This is a UNIX-style name that can
combine only with UNIX names specified explicitly in the
#include directive. It causes a specification like
<sys/types.h> to be considered first as /sys/types.h, which is
translated to SYS:TYPES.H.

2. Search the places specified in the /INCLUDE_DIRECTORY
qualifier, exactly as in Step 2 for the quoted form of
inclusion.

3. If "DECC$SYSTEM_INCLUDE" is defined as a logical name, search
"DECC$SYSTEM_INCLUDE:.H", or just "DECC$SYSTEM_INCLUDE:." if
/ASSUME=NOHEADER_TYPE_DEFAULT is in effect.

4. If "DECC$LIBRARY_INCLUDE" is defined as a logical name and
"DECC$SYSTEM_INCLUDE" is NOT defined as a logical name, search
"DECC$LIBRARY_INCLUDE:.H", or just "DECC$LIBRARY_INCLUDE:." if
/ASSUME=NOHEADER_TYPE_DEFAULT is in effect.

5. If neither "DECC$LIBRARY_INCLUDE" nor "DECC$SYSTEM_INCLUDE" are
defined as logical names, then search the default list of
places for plain text-file copies of compiler header files as
follows:

SYS$COMMON:[DECC$LIB.INCLUDE.DECC$RTLDEF].H
SYS$COMMON:[DECC$LIB.INCLUDE.SYS$STARLET_C].H

If the file is not found, perform the text library search
described in the next step.

6. Extract the simple filename and file type from the #include
specification and use the filename as the module name to search
a list of text libraries associated with that file type.

For any file type, the initial text libraries searched consist
of those named on the command line with /LIBRARY qualifiers.

If the /INCLUDE_DIRECTORY qualifier contained an empty string,
no further text libraries are searched. Otherwise,
DECC$TEXT_LIBRARY is searched for all file types.

If "DECC$LIBRARY_INCLUDE" is defined as a logical name, then no
further text libraries are searched. Otherwise, the subsequent
libraries searched for each file type are:

For ".H" or ".":

SYS$LIBRARY:DECC$RTLDEF.TLB
SYS$LIBRARY:SYS$STARLET_C.TLB

For any file type other then ".H" or ".":

SYS$LIBRARY:SYS$STARLET_C.TLB

7. If the previous step fails, search:

SYS$LIBRARY:.H

Under /ASSUME=NOHEADER_TYPE_DEFAULT, the default file type is
modified as usual.

Arne

Søg
Reklame
Statistik
Spørgsmål : 177428
Tips : 31962
Nyheder : 719565
Indlæg : 6407944
Brugere : 218877

Månedens bedste
Årets bedste
Sidste års bedste