Sémantique C ++ #include

Question

C'est un multiple de la question de la pré-instruction de traitement.

1 - <> ou "" ?

Hormis les infos trouvées sur le MSDN:

http://msdn.microsoft.com/en-us/library/36k2cdd4(SV.80).aspx

1.a: Quelles sont les différences entre les deux notations?
1.b: tous les compilateurs en œuvre de la même façon?
1.c: Quand vous utilisez le <>, et quand vous utilisez le "" (c'est à dire quels sont les critères que vous utiliseriez pour utiliser l'un ou l'autre pour un en-tête)?

2 - #inclure {TheProject/TheHeader.php} ou {TheHeader.php} ?

J'ai vu au moins deux façons de l'écrire inclut de son projet les en-têtes. Considérant que vous avez au moins 4 types d'en-têtes, c'est:

• privé des en-têtes de votre projet?
• les en-têtes de votre projet, mais qui sont l'exportation de symboles (et donc, "public")
• les en-têtes d'un autre projet de votre module de liens avec
• les en-têtes d'un compilateur ou de la bibliothèque standard

Pour chaque type d'en-têtes:

2.a: vous utilisez <> ou "" ?
2.b: souhaitez-vous inclure {TheProject/TheHeader.php}, ou avec {TheHeader.php} seulement?

3 - Bonus

3.a: avez-vous travailler sur le projet avec les sources et/ou les en-têtes dans un arbre de l'organisation (c'est à dire, des répertoires à l'intérieur des répertoires, par opposition à "tous les fichiers dans un répertoire") et quels sont les avantages/inconvénients?

Answer 1

Je l'utilise généralement <> pour le système d'en-têtes et les "" pour projet d'en-têtes. Comme pour les chemins, qui est seulement nécessaire si le fichier que vous voulez est dans un sous-répertoire d'un chemin.

par exemple, si vous avez besoin d'un fichier dans /usr/include/SDL/, mais seulement le fichier /usr/include/ est dans votre chemin, alors vous pouvez simplement utiliser:

#include <SDL/whatever.h>

Aussi, gardez à l'esprit que, à moins que le chemin vous mettez commence par un /, il est relatif au répertoire de travail courant.

EDIT POUR RÉPONDRE à un COMMENTAIRE: Ça dépend, si il y a seulement quelques comprend une bibliothèque, je venais de comprendre qu'il est sous-répertoire dans le chemin, mais si la bibliothèque possède de nombreux en-têtes (comme des dizaines) alors je préfère juste l'avoir dans un sous répertoire que je précise. Un bon exemple de ceci est Linux du système d'en-têtes. Vous les utilisez comme:

#include <sys/io.h>
#include <linux/limits.h>

etc.

MODIFIER POUR INCLURE une AUTRE BONNE RÉPONSE: en outre, s'il est concevable que deux ou plusieurs bibliothèques fournissent des en-têtes du même nom, puis le sous-répertoire solution fondamentalement donne à chaque en-tête d'un espace de noms.

Answer 2

Pour citer le standard C99 (un coup d'œil le libellé est identique à la norme C90, mais je ne peux pas le cut-n-coller à partir de cela):

Un prétraitement de la directive de la forme

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

provoque le remplacement de la la directive par la totalité du contenu de la source de fichier identifié par le séquence spécifiée entre l' " les délimiteurs. Le nom du fichier source est recherché dans une mise en œuvre-définis. Si ce la recherche n'est pas pris en charge, ou si le recherche échoue, la directive est retraité comme si elle lisait

# include <h-char-sequence> new-line

avec la même séquence contenue (y compris les > caractères, le cas échéant) de la directive d'origine.

Ainsi les endroits recherchés par #include "whatever" est un super-ensemble des emplacements recherchés par #include <whatever>. L'intention est que le premier style serait utilisé pour les en-têtes qui en général "appartiennent" à vous, et la seconde méthode serait utilisée pour les en-têtes qui "appartiennent" à l'compilateur/environnement. Bien sûr, il y a souvent des zones grises qui devez-vous utiliser pour Stimuler les en-têtes, par exemple? Je ne l'utiliserais #include <>, mais je ne discute pas trop si quelqu'un d'autre sur mon équipe voulait #include "".

Dans la pratique, je ne pense pas que quelqu'un paie beaucoup d'attention à la forme est utilisée tant que la construction n'est pas de le casser. Certes, je ne me souviens pas qu'il ne soit jamais mentionné dans une revue de code (ou le contraire, même).

Answer 3

Je vais aborder la deuxième partie de votre question:

J'utilise normalement <project/libHeader.h> lorsque j'inclus des en-têtes d'un tiers. Et "myHeader.h" lorsque vous incluez des en-têtes à l'intérieur du projet.

La raison pour laquelle j'utilise <project/libHeader.h> au lieu de <libHeader.h> est qu'il est possible que plusieurs bibliothèques aient un fichier "libHeader.h". Pour les inclure tous les deux, vous avez besoin du nom de la bibliothèque dans le nom de fichier inclus.

Answer 4

1.a: Quelles sont les différences entre les deux notations?

"" commence la recherche dans le répertoire où C/C++ fichier se trouve. <> commence la recherche dans -je répertoires et des emplacements par défaut (/usr/include). Deux d'entre eux en fin de compte rechercher les mêmes endroits, seul l'ordre est différent.

1.b: tous les compilateurs en œuvre de la même façon?

Je l'espère, mais je ne suis pas sûr.

1.c: Quand vous utilisez le <>, et quand vous utilisez le "" (c'est à dire quels sont les critères que vous utiliseriez pour utiliser l'un ou l'autre pour un en-tête)?

J'utilise "" quand le fichier à inclure est censé être à côté de fichier C, <> dans tous les autres cas. En particulier, DANS notre projet "tout public" inclure les fichiers sont dans un projet/répertoire include, j'ai donc utiliser <> pour eux.

2 - #inclure {TheProject/TheHeader.php} ou {TheHeader.php} ?

Comme l'a déjà souligné, xxx/nom de fichier.h vous permet de faire des choses comme diskio/ErrorCodes.h et netio/ErrorCodes.h

* privé-têtes de votre projet?

Privé de l'en-tête de mon sous-système dans le projet. Utiliser le "nom de fichier.h" Public de l'en-tête de mon sous-système dans le projet (pas visible en dehors du projet, mais accessible à d'autres sous-systèmes). L'utilisation ou , en fonction de la convention adaptée pour le projet. Je préfère utiliser

* les en-têtes de votre projet, mais qui sont l'exportation de symboles (et donc, "public")

comprennent exactement comme les utilisateurs de votre bibliothèque devrait inclure. Probablement

* les en-têtes d'un autre projet de votre module de liens avec

Déterminée par le projet, mais certainement à l'aide de <> * les en-têtes d'un compilateur ou de la bibliothèque standard Certainement <>, selon la norme.

3.a: avez-vous travailler sur le projet avec les sources et/ou les en-têtes dans un arbre de l'organisation (c'est à dire, des répertoires à l'intérieur des répertoires, par opposition à "tous les fichiers dans un répertoire") et quels sont les avantages/inconvénients?

Je travaille sur un projet structuré. Dès que vous avez plus d'une vingtaine de fichiers, une certaine division deviendra évidente. Vous devriez aller la façon dont le code est vous tirer.