423 votes

#pragma une fois vs incluent gardes ?

Je suis en train de travailler sur une base de code qui est connu pour s'exécuter uniquement sur windows et être compilé sous Visual Studio (il s'intègre étroitement avec excel, donc il ne va pas n'importe où). Je me demande si je doit aller avec la traditionnelle comprenant des protections ou utiliser #pragma once de notre code. Je pense que laisser le compilateur faire face avec #pragma once donnera plus rapide compile et est moins sujette aux erreurs lors de l'adaptation et de collage. Il est également un peu moins laid ;)

Note: pour obtenir la plus rapide temps de compilation que nous pourrions utiliser Redondant Inclure des Gardes , mais qui ajoute un couplage étroit entre le fichier inclus, et les fichiers. Habituellement, c'est ok parce que la garde doit être basé sur le nom de fichier et de ne changer si vous avez besoin de changer le nom de toute façon.

377voto

Brian R. Bondy Points 141769

Je ne pense pas que cela fera une différence significative dans le temps de compilation, mais #pragma once est très bien pris en charge sur les compilateurs, mais qui ne font pas partie de la norme. Le préprocesseur peut-être un peu plus rapide avec elle car elle est plus simple à comprendre votre intention.

#pragma once soit moins enclin à faire des erreurs et c'est moins de code à taper.

Pour accélérer le temps de compilation de plus en plus juste avant de déclarer au lieu de notamment dans .h les fichiers quand vous le pouvez.

Je préfère utiliser #pragma once.

Voir cet article de wikipedia à propos de la possibilité d'utiliser les deux.

189voto

Cookie Points 2599

Je voulais juste ajouter à cette discussion que je suis juste la compilation sur VS et de GCC, et utilisé pour donner des gardes. J'ai maintenant passé à #pragma once, et la seule raison pour moi n'est pas la performance ou de la portabilité ou la norme que je ne me soucie pas vraiment de ce qui est standard aussi longtemps que VS support de GCC, et qui est que:

#pragma once réduit les possibilités pour les bugs.

Il est très facile de copier et coller un fichier d'en-tête à l'autre en-tête de fichier, le modifier selon les besoins, et d'oublier de changer le nom de la garde. Une fois que les deux sont inclus, il vous prend un certain temps à traquer l'erreur, comme les messages d'erreur ne sont pas nécessairement claire.

40voto

Klaim Points 24511

Jusqu'au jour #pragma once devient la norme (qui n'est actuellement pas une priorité pour l'avenir des normes), je vous suggère de l'utiliser ET de l'utilisation de gardes, de cette façon:

#ifndef BLAH_H
#define BLAH_H
#pragma once

// ...

#endif

Les raisons sont les suivantes :

  • #pragma une fois n'est pas standard, donc il est possible que le compilateur ne fournit pas la fonctionnalité. Cela dit, tous les grands compilateur prend en charge. Si un compilateur ne le savent pas, au moins il sera ignoré.
  • Comme il n'existe aucune norme de comportement pour le #pragma une fois, vous ne devriez pas supposer que le comportement sera le même sur tous les compilateur. Les gardes s'assurer au moins que le postulat de base est le même pour tous les compilateurs qu'au moins à mettre en œuvre les instructions préprocesseur pour les gardiens.
  • Sur la plupart des compilateurs, #pragma once d'accélérer la vitesse de compilation (d'un rpc), car le compilateur ne va pas rouvrir le fichier contenant cette instruction. Afin de l'avoir dans un fichier peut aider, ou pas, selon le compilateur. J'ai entendu g++ pouvez faire la même optimisation lorsque les gardes sont détectées mais il à être confirmée.

En utilisant les deux ensemble, vous obtenez le meilleur de chaque compilateur pour cela.

Maintenant, si vous n'avez pas un script automatique pour générer les gardes, il peut être plus pratique de l'utiliser juste une fois #pragma. Juste savoir ce que cela signifie pour un code portable. (Je suis en utilisant VAssistX pour générer les gardes et pragma fois rapidement)

Vous devriez presque toujours pense que votre code de façon portable (parce que vous ne savez pas de quoi l'avenir est fait), mais si vous pensez vraiment qu'il n'est pas destiné à être compilé avec un autre compilateur (code très spécifique du matériel embarqué par exemple) alors vous devez simplement vérifier que votre compilateur de la documentation à propos de #pragma une fois pour savoir ce que vous êtes vraiment en train de faire.

26voto

Donnie DeBoer Points 1632

Si vous êtes positif que vous n’utiliserez jamais ce code n’importe où autre que Windows/VS, alors vous pouvez certainement utiliser #pragma une fois sans soucis.

Vous pouvez également utiliser les deux (voir exemple ci-dessous), pour que vous obteniez speedup de portabilité et de la compilation sur les systèmes compatibles

15voto

Michael Burr Points 181287

En général, je ne vous embêtez pas avec #pragma once que mon code ne sont, parfois, de devoir compiler avec autre chose que MSVC ou GCC (compilateur pour des systèmes embarqués n'ont pas toujours les #pragma).

J'ai donc utiliser #include gardes de toute façon. J'ai pu également utiliser #pragma once que certaines réponses suggèrent, mais il ne semble pas à être bien raison et il provoque souvent inutile d'avertissements sur les compilateurs qui ne le supportent pas.

Je ne suis pas sûr de ce que les économies de temps le pragma peut apporter. J'ai entendu dire que les compilateurs généralement déjà reconnaître quand un en-tête n'a rien, mais les commentaires en dehors de la garde des macros et fera l' #pragma once d'équivalent dans ce cas (c'est à dire., ne jamais traiter le fichier de nouveau). Mais je ne suis pas sûr si c'est vrai ou juste une affaire de compilateurs pourrait faire cette optimisation.

Dans les deux cas, il est plus facile pour moi d'utiliser #include gardes qui marche partout et vous inquiétez pas à ce sujet plus loin.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X