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

Citation:

---

Envoyé par 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 les modules C sont compilés en C.

Citation:

---

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.

Citation:

---

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

Citation:

---

Envoyé par DaZumba

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

---

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.

Citation:

---

Envoyé par Emmanuel Delahaye

Citation:

---

Envoyé par 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" ?

Citation:

---

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

Citation:

---

Envoyé par oodini

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:

---

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.

Citation:

---

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

Bonjour à tous,

J'ai besoin d'afficher des de l'arabe en utilisant le codage ISO. Je programme en C/C++.
SVP est-ce que qlq'un peut m'aider.
Merci d'avance

Citation:

---

Envoyé par sovop

J'ai besoin d'afficher des de l'arabe en utilisant le codage ISO. Je programme en C/C++.
SVP est-ce que qlq'un peut m'aider.

---

Rapport avec le sujet en cours ?

Tu aurais du créer un nouveau sujet au lieu de déterrer un vieux sujet comme ça qui n'a rien à voir...

Pour ta question, il faut sans doute que ton système dispose des fonts adéquates et que coté C, tu utlises les caractères larges (wchar_t) qui supportent Unicode et donc toutes les fonctions 'w', le préfixe L pour les chaines etc.

J'avoue ne pas en savoir beaucoup plus...

Citation:

---

Envoyé par sovop

Bonjour à tous,

J'ai besoin d'afficher des de l'arabe en utilisant le codage ISO. Je programme en C/C++.
SVP est-ce que qlq'un peut m'aider.
Merci d'avance

---

Un très bon topic, j'ai appris des choses, j'aurai jamais lu, si tu l'as pas déterré..

Pour ta question, tu dois déjà arriver à entrer les caractères arabes dans un programme tel notepad (bloc note), sinon impossible
Pour ce faire rendez-vous paneau de configuration, puis options linguistique et régionale et installe le clavier arabe (tu dois être muni du CD de windows)

PS: veuille tjrs à créer un nouveau post pour poser ta question, tu pollue l'atmosphère ici man :P

Citation:

---

Un très bon topic, j'ai appris des choses, j'aurai jamais lu, si tu l'as pas déterré..

---

++ :lol::aie: