Quel est l'intérêt de dire spécifiquement au compilateur d'inclure le fichier une seule fois ? Cela ne serait-il pas logique par défaut ? Y a-t-il même une raison d'inclure un seul fichier plusieurs fois ? Pourquoi ne pas simplement le supposer ? S'agit-il d'un matériel spécifique ?
Réponse
Trop de publicités?Dans le micrologiciel du produit sur lequel je travaille principalement, nous devons être en mesure de spécifier où les fonctions et les variables globales/statiques doivent être allouées en mémoire. Le traitement en temps réel doit vivre dans la mémoire L1 de la puce pour que le processeur puisse y accéder directement et rapidement. Les traitements moins importants peuvent être placés dans la mémoire L2 de la puce. Et tout ce qui n'a pas besoin d'être traité particulièrement rapidement peut vivre dans la DDR externe et passer par la mise en cache, parce que cela n'a pas d'importance si c'est un peu plus lent.
Le #pragma pour allouer où les choses vont est une longue ligne non triviale. Il serait facile de se tromper. L'effet d'une erreur serait que le code/données serait silencieusement placé dans la mémoire par défaut (DDR), et l'effet d'une erreur d'allocation serait que le code/données serait placé dans la mémoire par défaut (DDR). que peut être un contrôle en boucle fermée qui arrête de fonctionner sans raison, c'est facile à voir.
J'utilise donc des fichiers include, qui ne contiennent que ce pragma. Mon code ressemble maintenant à ceci.
Fichier d'en-tête...
#ifndef HEADERFILE_H
#define HEADERFILE_H
#include "set_fast_storage.h"
/* Declare variables */
#include "set_slow_storage.h"
/* Declare functions for initialisation on startup */
#include "set_fast_storage.h"
/* Declare functions for real-time processing */
#include "set_storage_default.h"
#endif
Et la source...
#include "headerfile.h"
#include "set_fast_storage.h"
/* Define variables */
#include "set_slow_storage.h"
/* Define functions for initialisation on startup */
#include "set_fast_storage.h"
/* Define functions for real-time processing */
Vous remarquerez de multiples inclusions du même fichier, même juste dans l'en-tête. Si je fais une erreur de frappe maintenant, le compilateur me dira qu'il ne peut pas trouver le fichier include "set_fat_storage.h" et je pourrai facilement le corriger.
Donc, pour répondre à votre question, il s'agit d'un exemple réel et pratique de cas où l'inclusion multiple est nécessaire.
- Réponses précédentes
- Plus de réponses
24 votes
Y a-t-il une raison d'inclure un seul fichier plusieurs fois ? \=> Cela pourrait être le cas. Un fichier peut avoir une compilation conditionnelle
#ifdefs
en elle. On peut donc dire#define MODE_ONE 1
et ensuite#include "has-modes.h"
et ensuite#undef MODE_ONE
con#define MODE_TWO 1
y#include "has-modes.h"
encore. Le préprocesseur est agnostique par rapport à ce genre de choses, et parfois elles peuvent avoir un sens.66 votes
Il serait logique qu'il s'agisse de la valeur par défaut. Mais pas celui qu'ils ont choisi lorsque les programmeurs C montaient encore à cheval, portaient des armes et avaient 16 Ko de mémoire.
1 votes
@FrançoisAndrieux mais le duplicata semble demander la même chose sur les gardes d'inclusion en général pas seulement #pragma une fois.
11 votes
Vous pouvez inclure
<assert.h>
plusieurs fois, avec des définitions différentes deNDEBUG
dans le même fichier source.1 votes
@FrançoisAndrieux Assez juste. Cela devrait être plus clair.
3 votes
Quant à
#pragma once
En soi, il existe des environnements matériels (généralement avec des lecteurs en réseau et la possibilité de plusieurs chemins vers le même en-tête) où cela ne fonctionnera pas correctement.0 votes
Il s'agirait d'un changement radical, et il faudrait trouver un nouveau moyen de le désactiver - deux bonnes raisons de ne pas le faire.
1 votes
Vous répondez tous dans les commentaires : la cible des dupes est toujours ouverte aux réponses...
0 votes
@BaummitAugen : Mais cette question ne porte pas sur
#pragma once
Ces réponses ne sont donc pas appropriées. La question porte sur les protections include.0 votes
Toutes les réponses dans ce fil de commentaires semblent s'appliquer exactement de la même manière aux gardes d'inclusion classiques qu'aux gardes d'inclusion.
#pragma once
afaict.0 votes
@BaummitAugen : Non pertinent. Le "duplicata" ne demande pas
#pramga once
donc une réponse expliquant uniquement comment#pragma once
ne fonctionne pas serait hors sujet. Remarquez comment la réponse à cette question ne parle pas des include-guards ou même des échecs de#pragma once
il parle plutôt des cas où les inclusions multiples sont utiles. Ce qui ne serait pas non plus une réponse appropriée à la "duplication".2 votes
@JohnnyCache dois-je interpréter votre dernier commentaire de manière à ce que vous ne soyez pas vraiment intéressé par une réponse, mais plutôt par un trolling et marquer votre question pour les modérateurs comme telle ?
0 votes
@SergeyA Je suis très intéressé par une réponse, mais le fait que les gens continuent de le marquer et de le démarquer comme duplicata est également curieux. En fait, c'est la raison pour laquelle j'ai commenté avec cette remarque, au lieu de l'éditer dans la question.
0 votes
Je me souviens de plusieurs inclusions des mêmes en-têtes utilisées dans
c
plus que nous ne l'utiliserions dansc++
. Un compilateur ne voudrait pas casser cette utilisation cependant.12 votes
Si vous avez
#pragma once
supposé, quel est le moyen de contrer ce défaut ?#pragma many
? Combien de compilateurs ont implémenté quelque chose comme ça ?1 votes
@JonathanLeffler Ce n'est cependant pas un véritable argument. Si le défaut
#pragma once
et une option de refus#pragma many
était implémentable et considéré comme une bonne idée au point que la norme le souhaite, les compilateurs l'implémenteraient. La question ici est essentiellement de savoir pourquoi cela ne se produit pas.1 votes
@MaxLanghof : Il s'agit principalement de souligner que le changement de la valeur par défaut nécessite un moyen de s'assurer que
<assert.h>
- pour citer (une fois de plus) l'exemple du C standard d'un en-tête qui doit pouvoir être inclus plusieurs fois dans une même UT avec (potentiellement) différents à chaque fois - continue de fonctionner correctement. Réalisation de#pragma once
le défaut ne se produira probablement pas parce qu'il perturberait le code de travail, et il y a déjà d'autres alternatives viables disponibles dans la norme. Un jour, peut-être, il pourrait y avoir#pragma STDC once
- ce qui serait nominalement la façon dont il serait normalisé.2 votes
TL;DR parce que le système de construction C++ est une vieille blague et que les programmeurs en sont venus à dépendre de ses bizarreries.
0 votes
Je ne veux pas savoir combien de combats de coulisses il y a eu sur la ré-utilisation
auto
.2 votes
Voir aussi #pragma once vs include guards ? et la partie #pragma once has unfixable bugs. Il ne devrait jamais être utilisé. D'après ce que j'ai compris, les en-têtes créés par des liens posent de nombreux problèmes.
1 votes
Duplicata possible de #pragma once vs include guards ?
2 votes
Hans Passant : Désolé, mais je monte toujours à cheval, et je suis connu pour porter une arme à feu lorsque je le fais, car il y a des ours et des pumas dans la nature.