IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C Discussion :

Compatibilité ANSI [FAQ]


Sujet :

C

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Expert éminent
    Avatar de Emmanuel Delahaye
    Profil pro
    Retraité
    Inscrit en
    Décembre 2003
    Messages
    14 512
    Détails du profil
    Informations personnelles :
    Âge : 68
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Décembre 2003
    Messages : 14 512
    Par défaut
    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 !)

  2. #2
    Membre éprouvé
    Profil pro
    Inscrit en
    Novembre 2004
    Messages
    2 766
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2004
    Messages : 2 766
    Par défaut
    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"...

  3. #3
    Expert éminent
    Avatar de Emmanuel Delahaye
    Profil pro
    Retraité
    Inscrit en
    Décembre 2003
    Messages
    14 512
    Détails du profil
    Informations personnelles :
    Âge : 68
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Décembre 2003
    Messages : 14 512
    Par défaut
    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

  4. #4
    Membre Expert
    Inscrit en
    Décembre 2004
    Messages
    1 478
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 1 478
    Par défaut
    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...

  5. #5
    Expert éminent
    Avatar de Emmanuel Delahaye
    Profil pro
    Retraité
    Inscrit en
    Décembre 2003
    Messages
    14 512
    Détails du profil
    Informations personnelles :
    Âge : 68
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Décembre 2003
    Messages : 14 512
    Par défaut
    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.
    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...

  6. #6
    Expert éminent
    Avatar de Emmanuel Delahaye
    Profil pro
    Retraité
    Inscrit en
    Décembre 2003
    Messages
    14 512
    Détails du profil
    Informations personnelles :
    Âge : 68
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Décembre 2003
    Messages : 14 512
    Par défaut
    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.

  7. #7
    Membre éprouvé
    Profil pro
    Inscrit en
    Novembre 2004
    Messages
    2 766
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2004
    Messages : 2 766
    Par défaut
    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" ?

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

  8. #8
    Expert éminent
    Avatar de Emmanuel Delahaye
    Profil pro
    Retraité
    Inscrit en
    Décembre 2003
    Messages
    14 512
    Détails du profil
    Informations personnelles :
    Âge : 68
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Décembre 2003
    Messages : 14 512
    Par défaut
    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 : 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...

Discussions similaires

  1. help!! problème de compatibilité ascendante
    Par valfredr dans le forum XMLRAD
    Réponses: 5
    Dernier message: 16/06/2003, 16h15
  2. [7RC3] Compatibilité avec les anciennes versions ...
    Par Sylvain Leray dans le forum XMLRAD
    Réponses: 3
    Dernier message: 15/05/2003, 16h46
  3. Programmation ANSI C++ ou Borland C++ ?
    Par scarabee dans le forum C++Builder
    Réponses: 5
    Dernier message: 04/11/2002, 19h00
  4. Compatibilité Visibroker 4.5 C++ Builder
    Par manuel dans le forum CORBA
    Réponses: 4
    Dernier message: 15/07/2002, 21h57
  5. compatibilité des librairies directX8
    Par Freakazoid dans le forum DirectX
    Réponses: 3
    Dernier message: 23/05/2002, 21h33

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo