Discussion :

[Emmanuel Delahaye]

C'est exactement ce qui se faisait avant la normalisation ANSI de 1989 (Idem ISO de 1990). On parle alors de codage K&R ou pré-ansi. Inutile de dire qu'avant cette époque, le C était un langage de gourous barbus et fumeur de pétards... des geeks, quoi...

Un peu comme le gars qui m'a répondu sur comp.lang.c ?
(voir sa page personnelle dont l'URL est dans la signature)

Ca m'a tout l'air d'être une caricature. ;-)

Mouarf! En tout cas, il a bien répondu. De toutes façons, le niveau de réponse de c.l.c. est probablement le meilleur qui soit, tout forums confondus. Il faut dire qu'il a été créé dès le début d'internet. C'est le premier forum Usenet, et, curiosité, un des rares à ne pas avoir de charte écrite, (mais une très bonne FAQ).

Il est fréquenté depuis toujours par les gourous du C. (Les vrais, les poilus, les barbus !)

[oodini]

C++ ajoute donc des 'décorations' (de Noël, hi hi!) internes assez farfelues genre :

• @@123abc@@func
  @@456def@@func
  @@789ghi@@func

En C++, c'est utile, mais si un source compilé en C++ appel une bête fonction C, il ne doit pas ajouter ces décorations démentielles, sinon, le linker ne va jamais retrouver la fonction C correspondante. Le role de extern "C" est donc d'empécher la déco...

Mais si le compilateur C++ utilise ces décorations sur des fichiers C, le linker devrait pouvoir correctement les exploiter. Je comprendrais mieux ton explication si on utilisait un compilateur C++, et un éditeur de lien C... ?

Au fait, comment aurais-je pu trouver cette information par moi-même ? J'ai cru écluser Google, et je ne tombais que sur des docs avec des macro "bateaux"...

[Emmanuel Delahaye]

Pour les conventions d'appel, il faut savoir que le C et le C++ n'appellent pas les fonctions de la meme facon (l'ordre des arguments sur la pile est different).

Bzzt. 'implementation-dependent'. Malgré des demandes répétées, il n'y a pas d'ABI[1] standard en C. (Ni en C++, à ma connaissance, très limité du sujet).

-------------------
[1] Application Binary Interface

[DaZumba]

Bzzt. 'implementation-dependent'.

Oui. Mais si C et C++ ont des conventions differentes au sujet de l'ordre des arguments sur la pile, alors extern "C" forcera la convention C. extern "C" ne concerne pas que la decoration (qui est compiler-dependent, elle...). M'enfin, on parle de C++, la...

[Emmanuel Delahaye]

Mais si le compilateur C++ utilise ces décorations sur des fichiers C, le linker devrait pouvoir correctement les exploiter.

Ben non, parce que la bibliothèque C et les modules C sont compilés en C.

Je comprendrais mieux ton explication si on utilisait un compilateur C++, et un éditeur de lien C... ?

Mamma mia! Un éditeur de lien est indépendant du langage. Il relie des objets compilés (code machine avec des listes d'étiquettes non résolues) pour en faire un fichier 'code machine' unique.

Au fait, comment aurais-je pu trouver cette information par moi-même ? J'ai cru écluser Google, et je ne tombais que sur des docs avec des macro "bateaux"...

Hum, ça fait 6 ans que je fréquente La Source, à savoir news:comp.lang.c plus quelques autres forums... Ce genre d'info ne tombe pas du ciel...

[Emmanuel Delahaye]

Bzzt. 'implementation-dependent'.

Oui. Mais si C et C++ ont des conventions differentes au sujet de l'ordre des arguments sur la pile, alors extern "C" forcera la convention C. extern "C" ne concerne pas que la decoration (qui est compiler-dependent, elle...). M'enfin, on parle de C++, la...

C'est de la touille interne. Mais pour que ça marche, il y a intérêt à ne pas mélanger les compilateurs (suite C/C++/Linker tout GCC ou tout Borland ou tout Microsoft, mais pas de mélange... Eviter aussi les écarts de versions trop importants (genre 16-bit d'un coté, 32-bit de l'autre...)

C'est pour ça qu'il existe des bibliothèques 'pour GCC', 'pour VC++6', pour 'Borland C' etc. Sinon, on récupère les sources et on recompile pour la suite qui va bien.

[oodini]

Mais si le compilateur C++ utilise ces décorations sur des fichiers C, le linker devrait pouvoir correctement les exploiter.

Ben non, parce que la bibliothèque C et le modules C sont compilés en C.

OK, je comprend mieux où se situe l'hétérogènéité.

Mais vos explications concernaient les fonctions, ou autres entités.
Or, c'est ici utilisé avec EXTERN, qui n'est pas une entité (ou un objet, comme on dirait en C++), mais une "portée".

Je suis donc un peu perplexe. Et pourquoi ces précautions de compilations ne sont-elles prises que sur "extern" ?

Hum, ça fait 6 ans que je fréquente La Source, à savoir news:comp.lang.c plus quelques autres forums... Ce genre d'info ne tombe pas du ciel...

Tu devrais mettre ce truc dans ta FAQ. car j'ai souvent trouvé ce bout de code sur Google, sans qu'il n'y ai jamais eu d'explications.
En tout cas, ton site a atterri directement dans mes signets. :-)

[Emmanuel Delahaye]

Mais vos explications concernaient les fonctions, ou autres entités.
Or, c'est ici utilisé avec EXTERN, qui n'est pas une entité (ou un objet, comme on dirait en C++), mais une "portée".

Je suis donc un peu perplexe. Et pourquoi ces précautions de compilations ne sont-elles prises que sur "extern" ?

Ca s'utilise comme ça :

EXTERN <declaration d'objet>;
ou
EXTERN <prototype de fonction>;

dans un header. Personnellement, je fais autrement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
Par exemple : 
 
#ifndef H_ED_HEADER_20050928172540
#define H_ED_HEADER_20050928172540
 
#ifdef __cplusplus
extern "C"
{
#endif
 
/* header.h */
 
#ifdef __cplusplus
}
#endif
 
#endif /* guard */
 
/* Guards added by GUARD (c) ED 2000-2005 Feb 07 2005 Ver. 1.7 */

je trouve ça plus simple, d'autant plus que chez moi, ce genre de code est généré automatiquement.

de plus, je vois mal un header mélangeant du C et du C++. Celui-ci est 'pur-C, mais il peut être inclus dans un source C++ sans broncher.

Tu devrais mettre ce truc dans ta FAQ. car j'ai souvent trouvé ce bout de code sur Google, sans qu'il n'y ai jamais eu d'explications.

Aie... Mise à jour de la TODO list...