Pourquoi n'y a-t-il pas de protecteur d'inclusion dans les fichiers d'en-tête Numerical Recipes?

Question

programmeur C++ novice ici. J'utilise le code source Recettes numériques (V3) dans le cadre d'un projet C++ modulé plus grand.

Alors que je vais essayer de ne pas entrer dans les détails de mon problème, je suis curieux de savoir pourquoi ces fichiers d'en-tête NR n'incorporent pas de gardes d'en-tête? Je suis conscient que cette question est très spécifique à ceux qui ont utilisé ce code dans le passé, mais en regardant les forums NR, ils semblent tout à fait inactifs ...

Les erreurs que je trouve avec mon code qui a provoqué cette question sont;

erreur LNK2005: "void __cdecl gaussj (classe NRmatrix &)" déjà défini dans Schmidt_V2_ (Zeta) .obj

erreur LNK2005 (gaussj @@ YAXAAV $ NRmatrix @ N @@@ Z?): " vide __cdecl gaussj (classe NRmatrix &, classe NRmatrix &) »(? gaussj @@ YAXAAV? $ NRmatrix @ N @ @@ 0 Z) déjà défini dans Schmidt_V2_ (Zeta) .obj

Answer 1

AFAIK il n'y a pas une bonne raison. Il y a quelques situations où vous pourriez légitimement vouloir ne pas utiliser un gardien d'inclusion (voir this question), mais ce n'est pas l'un d'entre eux.

Si vous devez inclure les en-têtes de plusieurs endroits dans votre projet, vous devez présenter vos propres gardes, comme ceci:

#include <a_normal_thing> 
#include <another_normal_thing> 

#ifndef SPECIAL_NONESENSE_H 
#define SPECIAL_NONESENSE_H 
#include <special_nonsense> 
#endif 

// More normal includes... 

Ceci est bavard et ennuyeux, mais ça va marcher.

EDIT: Ou de nos jours, il est assez sûr d'utiliser #pragma once comme Donnie le suggère dans un commentaire ci-dessous. Cela ne fonctionnera pas dans les versions de GCC antérieures à 3.4, mais vous n'avez probablement plus besoin de le supporter.