Duplicaté possible:
Quelle est la différence entre #includeet # Inclure "nom de fichier" Y a-t-il une différence fondamentale entre la syntaxe de deux #include, à part le chemin du chemin le compilateur recherchera?
J'ai le sentiment que le compilateur d'Intel ne donne pas exactement la même sortie.
8 Réponses :
La différence fondamentale est dans laquelle des chemins sont recherchés.
Vous êtes censé utiliser le formulaire de support d'angle pour "système" inclut et des citations ordinaires pour le projet-local comprennent.
En pratique, cela peut être vrai, mais la vraie différence, conformément à la norme de langage C, est de savoir si le compilateur doit rechercher un Header ou un fichier . (Astuce: les en-têtes ne doivent pas nécessairement être des fichiers, bien qu'ils soient presque toujours).
Intéressant ... re «les en-têtes ne doivent pas nécessairement être des fichiers». Excusez mon ignorance, que peuvent-ils être d'autre?
@Rich: Par exemple, ils pourraient être compilateurs / préprocesseurs intégrés. Plutôt que de rechercher un fichier sur le système de fichiers, le préprocesseur pourrait simplement insérer du code codé dur en soi lorsque des en-têtes standard sont inclus. Ou il pourrait interroger une base de données pour le contenu de l'en-tête, téléchargez l'en-tête d'Internet ... vous obtenez l'idée. Mais si au lieu de demander
Considérons des en-têtes prétraités, où le pré-processeur / compilateur n'a pas à passer par la source d'en-tête du tout ...
devillait instruire de rechercher d'abord dans le répertoire actuel, puis dans les répertoires système (chemin de trail recomposé dans le compilateur / préprocesseur ou spécifié avec La sortie du compilateur ne dépend certainement pas des guillemets car il est traité à la phase de prétraitement. Sauf que le cas échéant sur le comportement de recherche modifié, différents fichiers sont inclus. -i ). En utilisant les crochets d'angle , vous désactivez d'abord la recherche du répertoire actuel.
Dans la mesure où les citations et les crochets d'angle diffèrent, ils le font, car le concepteur de compilateur a estimé qu'elles devraient, et non à cause de tout dictateur de la norme.
@Nick: La norme dit qu'ils devraient différer, mais cela ne dit pas que c'est l'algorithme de recherche qui devrait différer.
Nick, plus ou moins Tous Compilit Designers. Ça compte, n'est-ce pas? ;-)
Il n'y a pas de différence technique en général, et tout ce qui vous en dit un style local, probablement influencé par les compilateurs passés - de nombreux compilateurs modernes implémentent la recherche initiale de la même manière (souvent d'autres comportements courants sont disponibles via la ligne de commande. option). La norme laisse le comportement entre les mains de l'exécutant, sans justification particulière pour supporter les deux syntaxes.
Selon la section 6.10.2 de la norme ISO C99, les chemins de recherche pour <> et "" sont tous deux définis par la mise en œuvre . La seule différence entre eux dans les yeux de la norme est qu'utiliser "" tombera sur <> s'il ne peut pas être résolu. (Ne soyez pas déclenché par la norme semblant de faire une distinction entre «en-tête» et «fichier source» - il n'y a pas de différence réellement définie par la norme autre que le fait que certains noms sont réservés - «Stdia.h ", etc.)
Si vous lisez un peu plus de plus près la norme, vous verrez que <> s'applique à en-têtes tandis que "" s'applique à fichiers source . Notez que le "fichier source" tel qu'utilisé par la norme ne signifie pas la même chose qu'il connote généralement dans une conversation familière.
@Dan moulage: et cela importerait réellement si la norme a formulé une distinction substantielle entre les fichiers source et les en-têtes, mais cela ne le fait en fait pas.
La différence substantielle est qu'un en-tête n'a pas besoin de résider dans le système de fichiers ...
La norme peut bien dire que, mais ce n'est pas toujours le cas.
@DevSolar: "Fichiers sources" n'a pas besoin de résider dans le système de fichiers non plus - la norme n'utilise jamais un tel mot ni le définir. En fait, la raison même que ces choses sont définies sur la mise en œuvre, c'est que la norme ne présume pas comment les "fichiers" sont stockés dans votre système d'exploitation (sinon des systèmes de fichiers orientés enregistrés dans des systèmes d'OSES tels que VMS ne pourraient pas supporter un compilateur C)
@Chris Huang-Lever: Bien sûr, c'est toujours le cas - la mise en œuvre définie signifie qu'il n'y a pas de mise en œuvre non conforme. La seule vraie réponse à cette question dans le domaine spécifique est si quelqu'un sondait tous les compilateurs modernes et détermine leur comportement.
@DevSolar: à partir de la section pertinente de la norme (5.1.1.2 (5)) - «Les fi les, ... ne doivent pas nécessairement être stockés comme des fichiers, ni n'ont besoin d'une correspondance individuelle entre ces entités et tout représentation externe. "
Note de bas de page 159 au 7.1.2 (1): "Un en-tête n'est pas nécessairement un fichier source, pas plus que les séquences
La norme de langage C indique que Lorsque la standard parle des "en-têtes", il ne parle pas spécifiquement de les fichiers du tout. La norme ne nécessite pas d'en-têtes pour exister en tant que fichiers. Ils pourraient être intégrés au compilateur pour tous les standards standard.
donc la différence réelle entre En pratique, les compilateurs utilisent différents algorithmes de recherche pour <> doit être utilisé pour "les en-têtes" et "" " doit être utilisé pour" Fichiers source ". Maintenant, ne vous mettez pas tous dans les bras sur la chose "Fichiers source". Lorsque la norme indique "Fichiers Source", cela ne signifie pas ce que vous pensez. Le terme "fichiers source" tel qu'utilisé dans la norme englobe ce que nous appelons de manière colloquante "Fichiers d'en-tête" (en plus de ce que nous appelons couramment "Fichiers Source").
<> et "" est que <> est utilisé pour Les en-têtes et "" sont utilisés pour fichiers . Si vous savez que la source, vous y inclure est un fichier vous devez utiliser "" . .
<> contre "" . Ceci est autorisé par la norme que l'algorithme de recherche à utiliser pour l'un ou l'autre est la mise en œuvre définie . Mais ce n'est pas la vraie différence comme exprimée par la norme.
J'ai fait à l'occasion piraté une source pour inclure réellement un fichier .C. Ce n'était pas bien, je ne le recommanderais pas, mais c'est bien possible. Qu'est-ce que vous #include n'a pas d'importance, tant que le résultat est valide C Source. ;-)
@DevSolar: En effet. Mais d'où je viens de #incluant un fichier .C est considéré comme pur mal. :)
Ici aussi. Mais je me sentais comme ça. ;-) (En réalité, c'était ce que vous appelleriez un "cours à grande vitesse" en C pour UNIX, où l'instructeur et les deux élèves américains ont traversé 460 pages de livre dans cinq jours. J'avais besoin des mêmes fonctions encore et encore une fois Jour, mais les pauses n'ont jamais été suffisamment longues pour en faire une configuration appropriée à deux-c-and-one-h-plus-makefile que cela aurait dû être, alors j'ai simplement inclus cet autre fichier C. L'instructeur était tout à fait ... agité quand il a vu ce que je faisais. ;-)
Pertinente: implémentation dans G ++ et dans Visual C ++
Le moulage DAN a eu raison; Détendez-vous, Hacker et Nick Bastin vous ont tort. Désolé.
#include "..."
Et si vous pouvez indiquer à la place dans la norme où "fichier source" est défini comme différent de "en-tête", vous pouvez rester sur votre High Horse. La seule mention réelle d'une tentative de définition de «fichier source» est dans une note de bas de page indiquant (au 5.1.1.2 (5)): «Source fi les, ... ne doit pas nécessairement être stocké comme des fichiers, ni n'ont besoin de une correspondance individuelle entre ces entités et toute représentation externe. "
En outre, dans la justification de la norme C99 - "la principale raison selon laquelle les règles explicites n'étaient pas incluses dans la norme sont l'infaisabilité de la description d'une structure de système de fichiers portable". (6.10.2-5) La seule différence entre les "en-têtes" et les "fichiers source" est que la norme se réserve certains noms de fichier d'en-tête - "La norme spécifie un ensemble d'inscrits de noms de fichiers qui doivent définir des noms de fichiers hôtes distincts. En l'absence d'une telle exigence, il serait impossible d'écrire des programmes portables à l'aide de fichiers inclus. " (6.10.2-15)
Je ne voulais pas "monter le haut cheval". J'ai toujours eu l'impression que la norme considérée comme des en-têtes et des fichiers sources pour être deux pas nécessairement des choses identiques et argumenté de cette position. Recherche sur le doc, je trouve le 5.1.1.1.1 (1), 6.4.7 (2), 6.10.2, Note de bas de page 156) aux 7.1.2 et 7.1.2 (3) pour soutenir la notion selon laquelle les en-têtes et les fichiers source doivent être deux choses différentes.
AVERTISSEMENT: Ceci est une spéculation pure. Je n'ai pas assez d'expérience avec le compilateur Intel à savoir si cela fonctionne de cette façon, je suis au courant de tout compilateur qui fait.
Si un compilateur implémente des en-têtes pré-compilés, il peut utiliser celles-ci pour une forme d'inclure, mais pas l'autre. Si l'en-tête pré-compilé sort de la synchronisation avec l'en-tête réel, vous obtiendrez des résultats différents selon lesquels était inclus.
Pour le compilateur GCC, il est différence entre les en-têtes <> et "". Si <> L'en-tête est inclus dans le répertoire fourni sous la forme d'ystem au préprocesseur, les avertissements ne sont pas émis pour l'en-tête inclus. Avec compilateur Intel a également une directive -Système, il peut ainsi être applicable à la CPI.
Laisser seul la différence de répertoires de recherche trop évidente à noter.
Vérifiera que le système inclut les chemins (y compris tout chemin supplémentaire ajouté pour un projet).
vérifiera le dossier de travail des applications. (c'est-à-dire le même dossier que le fichier source qui possède la déclaration #include de cela). #include #include "quelquefile.h"
Que voulez-vous dire "ne donne pas exactement exactement la même sortie"?
Il n'est pas censé être censé être - pouvez-vous donner plus de détails et d'exemple de sortie?
Absolument aucune différence dans la sortie de GCC avec "stdio.h" ou.
Dupliquer de: stackoverflow.com/questions/21593/...
@DMCKEE: Ce n'est pas un duplicata. Les réponses que vous connaissez sur (incorrectement) indiquent la différence correspond à la manière dont la recherche est effectuée. Cette nouvelle question concerne s'il y a quelque chose d'autre en plus de la recherche différente (c'est-à-dire qu'elle s'appuie sur l'autre question).
Ok ... par différentes sorties, je voulais dire que VC ++ m'a donné un avertissement (pertinent) avec le #include "", et cela ne pouvait pas détecter le problème avec le #include <>.