Je travaille sur un projet qui a beaucoup de code C hérité . Nous avons commencé à écrire en C ++, avec l'intention de convertir éventuellement le code hérité également. Je suis un peu confus quant à la façon dont le C et le C ++ interagissent. Je comprends qu'en enveloppant le code C avec extern "C"
le compilateur C ++, les noms du code C ne seront pas modifiés , mais je ne sais pas exactement comment implémenter cela.
Donc, en haut de chaque fichier d'en-tête C (après les gardes d'inclusion), nous avons
#ifdef __cplusplus
extern "C" {
#endif
et en bas on écrit
#ifdef __cplusplus
}
#endif
Entre les deux, nous avons tous nos inclus, typedefs et prototypes de fonctions. J'ai quelques questions, pour voir si je comprends bien:
Si j'ai un fichier C ++ A.hh qui comprend un fichier d'en-tête C Bh, comprend un autre fichier d'en-tête C Ch, comment cela fonctionne-t-il? Je pense que lorsque le compilateur
__cplusplus
entrera dans Bh, sera défini, donc il encapsulera le code avecextern "C"
(et__cplusplus
ne sera pas défini à l'intérieur de ce bloc). Ainsi, quand il__cplusplus
entrera dans Ch, il ne sera pas défini et le code ne sera pas encapsuléextern "C"
. Est-ce correct?Y a-t-il quelque chose de mal à envelopper un morceau de code avec
extern "C" { extern "C" { .. } }
? Que fera le secondextern "C"
?Nous ne mettons pas ce wrapper autour des fichiers .c, seulement les fichiers .h. Alors, que se passe-t-il si une fonction n'a pas de prototype? Le compilateur pense-t-il que c'est une fonction C ++?
Nous utilisons également du code tiers qui est écrit en C , et n'a pas ce genre d'enveloppe autour. Chaque fois que j'inclus un en-tête de cette bibliothèque, j'ai mis un
extern "C"
autour de #include. Est-ce la bonne façon de gérer cela?Enfin, cette configuration est-elle une bonne idée? Y a-t-il autre chose que nous devrions faire? Nous allons mélanger C et C ++ dans un avenir prévisible, et je veux m'assurer que nous couvrons toutes nos bases.