Compatibilité ANSI

Bonjour,

Quelqu'un pourrait-il m'expliquer le bout de code suivant ? Merci.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

#undef _ANSI_ARGS_ #undef const   #if (defined(__STDC__) && !defined(NO_PROTOTYPE)) || defined(__cplusplus) # define _USING_PROTOTYPES_ 1 # define _ANSI_ARGS_(x) x # define CONST const # ifdef __cplusplus # define VARARGS (...) # else # define VARARGS () # endif #else # define _ANSI_ARGS_(x) () # define CONST #endif   #undef EXTERN #ifdef __cplusplus # define EXTERN extern "C" #else # define EXTERN extern #endif

---

Citation:

---

Envoyé par oodini

Quelqu'un pourrait-il m'expliquer le bout de code suivant ?

---

Ouh là, t'es sûr ? C'est du code d'implémentation pour gourou de niveau 3 (sur une echelle de 5).
<...>
Avant de passer une plombe à decoder du source 'pas pour les clients', tu veux faire quoi exactement. Tu n'as pas lu l'étiquette :

http://www.lenoxx.com/manuals/CR446/COVERP2C.jpg http://www.coomber.co.uk/gifs/ProdSp...ANGERtools.gif

Ben j'ai récupéré un programme graphique de bonne taille que j'aie assez bien compris, mais j'avoe que ces hhistoires de directives du préprocesseur me laissent pantois... J'aimerais toutefois bien en evnir à bout.

J'aime bien tout comprendre. :-)

Citation:

---

Envoyé par oodini

Ben j'ai récupéré un programme graphique de bonne taille que j'aie assez bien compris, mais j'avoe que ces hhistoires de directives du préprocesseur me laissent pantois... J'aimerais toutefois bien en evnir à bout.

J'aime bien tout comprendre. :-)

---

En fait c'est assez simple su tu sais ce qu'est une macro. Qu'est-ce que tu ne comprends pas exactement ?

Citation:

---

#undef _ANSI_ARGS_
#undef const

#if (defined(__STDC__) && !defined(NO_PROTOTYPE)) || defined(__cplusplus)

---

Je comprend:
SI:
* le compilateur se déclare compatible au standard ANSI et s'il reconnait les prototypes de fonction
OU
* le compilateur est un comilateur C++

Code:

---

# define _USING_PROTOTYPES_ 1

---

On définit une macro disant qu'on peut utiliser des prototypes.

Code:

---

# define _ANSI_ARGS_(x) x

---

Là, je ne comprend pas.

Code:

---

# define CONST const

---

Quel intérêt ?

Code:

---

1 2 3 4 5 6 7 8 9

# ifdef __cplusplus # define VARARGS (...) # else # define VARARGS () # endif #else # define _ANSI_ARGS_(x) () # define CONST #endif

---

Là, je ne comprend rien (mes carences ne doivent pas se situer uniquement au niveau des macros).
Et ça veur dire quoi, #define CONST si on ne met rien derrière ?

Code:

---

1 2 3 4 5 6

#undef EXTERN #ifdef __cplusplus # define EXTERN extern "C" #else # define EXTERN extern #endif

---

Je en comprend pas le
#define EXTERN extern "C"


MERCI !

Citation:

---

Envoyé par oodini

Code:

---

# define _ANSI_ARGS_(x) x

---

Là, je ne comprend pas.

---

Definition d'une macro qui prend en argument x (une liste d'argument) et qui renvoie x. En gros, elle ne modifie rien. Par contre, elle est definie differemment plus bas, et la ne renvoie rien. Cela permet de ne pas donner de prototypes a un compilateur qui ne les comprend pas. En clair:

Code:

---

1 2	int function _ANSI_ARGS((int arg1, float arg2));

---

renverra

Code:

---

1 2	int function(int arg1, float arg2);

---

si le compilateur comprend les prototypes C90,

Code:

---

1 2	int function();

---

si le compilateur ne les comprend pas.

Citation:

---

Code:

---

# define CONST const

---

Quel intérêt ?

---

S'assurer que la casse (minuscule/majuscule) ne pose pas de probleme.
EDIT: Cela a un interet bien plus important, cf. le post d'Emmanuel Delahaye ci-dessous.

Citation:

---

Code:

---

1 2 3 4 5 6

# ifdef __cplusplus # define VARARGS (...) # else # define VARARGS () # endif #endif

---

---

C'est difficile a dire. Vu le nom, il semble que cela definit la syntaxe des fonctions a nombre d'arguments variables, mais le C utilise la meme syntaxe que le C++ dans ce cas-la, donc je ne vois pas trop. Il faudrait voir comment cette macro est utilisee.

Citation:

---

Et ça veur dire quoi, #define CONST si on ne met rien derrière ?

---

On definit juste CONST comme etant une macro existante (un #ifdef retournera vrai, un #ifndef retournera faux). C'est similaire a #define CONST 1
EDIT: Meme remarque que plus haut.

Citation:

---

Je en comprend pas le
#define EXTERN extern "C"

---

C'est pour le C++, pour indiquer que la fonction externe utilise les conventions d'appel du C. En C, ce n'est evidemment pas necessaire.

Citation:

---

Envoyé par DaZumba

Citation:

---

Code:

---

# define CONST const

---

Quel intérêt ?

---

S'assurer que la casse (minuscule/majuscule) ne pose pas de probleme.

---

Euh non ! Voir plus loin.

Citation:

---

Citation:

---

Et ça veur dire quoi, #define CONST si on ne met rien derrière ?

---

On definit juste CONST comme etant une macro existante (un #ifdef retournera vrai, un #ifndef retournera faux). C'est similaire a #define CONST 1

---

A ma connaissance, c'est vrai en C99 mais pas en C90...

En fait, ton analyse est erronée.

Le but de cette manip est que l'utilisateur utilise CONST au lieu de const dans son code, pour le rendre compatible avec le C pré-ANSI[1] (pas de const). Ensuite, grace à la compilation conditionelle, CONST est défini 'const' ou <rien>, ce qui se traduit par :

Code:

---

char CONST * p -> char const *p

---

ou

Code:

---

char CONST * p -> char *p

---

------------
[1] En C pré-ANSI, __STDC__ n'est pas défini

Citation:

---

Envoyé par Emmanuel Delahaye

En fait, ton analyse est erronée.

---

En effet, je te remercie de m'avoir corrige. J'ai edite mon post pour renvoyer au tien. Tu as une idee pour les VARARGS ?

Citation:

---

Envoyé par DaZumba

Citation:

---

Envoyé par oodini

Code:

---

# define _ANSI_ARGS_(x) x

---

Là, je ne comprend pas.

---

Definition d'une macro qui prend en argument x (une liste d'argument) et qui renvoie x. En gros, elle ne modifie rien. Par contre, elle est definie differemment plus bas, et la ne renvoie rien. Cela permet de ne pas donner de prototypes a un compilateur qui ne les comprend pas. En clair:

Code:

---

1 2	int function _ANSI_ARGS((int arg1, float arg2));

---

renverra

Code:

---

1 2	int function(int arg1, float arg2);

---

si le compilateur comprend les prototypes C90,

Code:

---

1 2	int function();

---

si le compilateur ne les comprend pas.

---

Mais dans le dernier cas, comment le code peut-il être exploitable ?
Ou alors, je ne comprend pas très bien comment utiliser une fonction lorsqu'on ne peut définir de prototype.
Est-ce à dire que les anciens compilateurs ne faisaient aucune vérification quant à la "signature" de la fonction ? Ne vérifiaient ni le type des arguments, ni leur nom, ni leur nombre ?

J'ai trouvé ce qui semble être une réponse dans la FAQ. Si vous avez des précisions à apporter...[/url]

Citation:

---

Envoyé par Emmanuel Delahaye

Le but de cette manip est que l'utilisateur utilise CONST au lieu de const dans son code, pour le rendre compatible avec le C pré-ANSI[1] (pas de const). Ensuite, grace à la compilation conditionelle, CONST est défini 'const' ou <rien>.

---

Merci, c'est clair. :-)

Citation:

---

Envoyé par DaZumba

Citation:

---

Envoyé par Emmanuel Delahaye

En fait, ton analyse est erronée.

---

En effet, je te remercie de m'avoir corrige. J'ai edite mon post pour renvoyer au tien. Tu as une idee pour les VARARGS ?

---

C'est vrai que cela reste un des derniers points à éclaircir, après vos fort utiles interventions.

Citation:

---

Envoyé par DaZumba

Citation:

---

Je en comprend pas le
#define EXTERN extern "C"

---

C'est pour le C++, pour indiquer que la fonction externe utilise les conventions d'appel du C. En C, ce n'est evidemment pas necessaire.

---

Qu'entends-tu par "les conventions d'appel" du C ?

Citation:

---

Envoyé par oodini

Mais dans le dernier cas, comment le code peut-il être exploitable ?
Ou alors, je ne comprend pas très bien comment utiliser une fonction lorsqu'on ne peut définir de prototype.
Est-ce à dire que les anciens compilateurs ne faisaient aucune vérification quant à la "signature" de la fonction ? Ne vérifiaient ni le type des arguments, ni leur nom, ni leur nombre ?

---

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... (Stallman[1] et autres...). Les nerds de l'époque (Wirth[2] etc.) regardant ce langage peu fiable avec mépris...

Les prototypes ont été une révolution très importante dans l'amélioration de la qualité du code C. Malheureusement, on a hérité de 'vieux' code (legacy code) à la mode pré-ansi, et certains ont jugé qu'il ne fallait rien toucher.

Les implémenteurs de bibliothèques ont alors imaginé des mécanismes tordus comme ceux-ci pour pouvoir supporter les deux modes. De nos jour, tout celà est anecdotique, car on est censé ecrire des fonctions avec prototypes (sépares ou non).

Mais bon, il existe des gens dont le compteur de temps est resté bloqué en 1973...

------------------------
[1] http://www.wfu.edu/~mudayja/images/st-gnu.jpg

[2] http://www.adeptis.ru/vinci/niklaus_wirth3.jpg

Citation:

---

Envoyé par 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. ;-)

Citation:

---

Envoyé par oodini

Je en comprend pas le
#define EXTERN extern "C"

Citation:

---

Envoyé par Dazumba

C'est pour le C++, pour indiquer que la fonction externe utilise les conventions d'appel du C. En C, ce n'est evidemment pas necessaire.

---

Qu'entends-tu par "les conventions d'appel" du C ?

---

C'est pas un problème de convention d'appel (qui est un problème d'implémentation), mais de 'décoration'.

En C, le nom 'réel' des fonctions et objets publics (vues par le linker) est à peu de choses près celui que l'on met dans le code. Par exemple :

func -> 'func' ou '_func' ou '.func' etc.

Par contre, en C++, les fonctions peuvent étre 'polymorphes' :

• int func (int)
  void func (char *)
  char *func (T *)

Comme au moment du link, il faut bien les différencier (ben oui, en ralité, il y a plusieurs fonctions, hé hé, ils sont malins les gens du C++, il nous font font croire au père Noël, mais je les ai démasqués!).

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...

Evidemment, si tu demandes aux grands gurus du C sur clc, je fais pale figure. Il t'a repondu sur le probleme de VARARGS, ceci dit (qui est un probleme similaire a CONST, donc, s'assurer qu'un compilateur C pre-ANSI puisse compiler les sources. Comme ils mettent le compilateur C++ dans le meme sac que le pre-ANSI (assez bizarrement, d'ailleurs), ils doivent remettre le comportement normal (...) pour le C++).

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). Egalement, le C++ decore les noms de fonction pour pouvoir utiliser le meme nom de fonction avec des arguments de type different. Bref, pour pouvoir utiliser une fonction C, le C++ doit savoir comment l'appeler et quel nom appeler. extern "C" lui dit cela.

Citation:

---

Envoyé par oodini

Citation:

---

Envoyé par 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 !)

Citation:

---

Envoyé par Emmanuel Delahaye

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"...

Citation:

---

Envoyé par DaZumba

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

Citation:

---

Envoyé par 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...