Lors de la discussion des possibilités de conception pour un projet qui a un très grand nombre de constantes et de modèles de bits à définir, la question s'est produite sur le nombre de #defines une poignée de compilateur standard? Je suppose que c'est un très grand nombre, mais nous étions curieux de savoir s'il y a une limite supérieure réelle.
3 Réponses :
Je n'ai jamais entendu parler de quelqu'un qui court. Jamais.
pour un "compilateur standard":
5.2.4.1: "Limites de traduction"
La mise en œuvre doit être en mesure de Traduire et exécuter au moins un programme qui contient au moins un cas de chacun des éléments suivants limites
...
Identificateurs macro 4095 simultanément défini dans un prétraitement unité de traduction
Notez la manière légèrement étrange de formuler l'exigence. Les implémentations pourraient le satisfaire en disposant d'un seul "programme d'or" qu'ils reconnaissent et compilent en tant que cas particulier, bien que cela ressemble à des points de repère de gréement. En pratique, vous pouvez lire la norme comme indiquant que si votre implémentation impose une limite autre que la mémoire disponible, alors que la limite devrait être au moins 4095. Au-delà de 4095, vous comptez sur un comportement spécifique à la mise en œuvre dans une mesure .
Certains compilateurs (Microsoft) imposent des limites de mise en œuvre inférieures à la norme. Celles-ci sont énumérées quelque part sur MSDN, je pense, mais éventuellement uniquement pour C ++. En ce qui concerne C va, depuis que je cite C99, cela pourrait ne pas être pertinent pour MSVC de toute façon.
pour GCC et MSVC en particulier, il ne devrait pas être trop difficile de tester si une mise en œuvre donnée impose une limite arbitraire, peut-être plus facile que de la trouver documentée :-) Générez automatiquement des fichiers ne contenant que de grandes listes longues de
#define , voir quel préprocesseur en fait.
Merci. Oui, je vais probablement essayer l'expérience de génération automatique éventuellement juste pour les sources ...
Le pré-processeur C n'élargne pas (puits pour que vous puissiez effectuer plusieurs fichiers ...) Vous pouvez faire exploser une course de prétraitement en développant des macros profondément imbriquées, je suppose. Quelque chose comme devrait faire l'affaire, car elle vous donne 2 ^ 64 copies d'un, ouc. Afair, ces définitions de macro sont même dans les limites que la norme impose. #define avant qu'ils ne soient utilisés. Donc, dans une implémentation typique, la seule limite que vous pourriez rencontrer est la mémoire de stocker tout cela. Mais cette mémoire pour stocker la représentation interne des macros sera fondamentalement quelque chose de proportionnelle à la taille des fichiers que le compilateur se lit.
"Ces définitions de macro sont même dans les limites que la norme impose" - pas tellement dans "4095 caractères dans une source de source logique", je pense que cela fait référence aux lignes après le prétraitement.
@Steve: Les définitions de macros sont, mais pas la seule expansion d'eux. Mais vous pouvez même faire exp () , alors adjacent whitespace {sh | c | w} ould être collé ensemble et toujours la compilation exploserait.
D'accord, il est possible de rendre le préprocesseur / compilateur à manquer de mémoire sans casser les limites spécifiques mentionnées dans la norme.