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

  1. #1
    Responsable 2D/3D/Jeux

    Introduction à la programmation d'applications modulaires en C++
    Bonjour à tous,

    Voici l'introduction d'une petite série d'articles, traduit par Eric GERARD, dans laquelle vous allez avoir obtenir des pistes de réflexion et des méthodes pour créer des applications modulaires.

    Bonne lecture
    Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  2. #2
    Responsable 2D/3D/Jeux

    Voici la première partie.

    Bonne lecture.
    Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  3. #3
    Responsable 2D/3D/Jeux

    Et la seconde partie :

    Bonne lecture.
    Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  4. #4
    Membre émérite
    Rapidement,

    L’introduction est assez bien, assez claire, et présente rapidement le principe de plugin. La première partie détaille la réalisation.

    Un gros soucis quand même : la mémoire allouée pour l’objet principal du plugin n’est jamais libérée. Je sais que c’est une traduction, mais quand même, ça la fout mal.

    Quelques erreurs en revanche dans le dernière partie :
    On peut remarquer ce problème avec des systèmes d'exploitation à la sauce UNIX. Un format souvent utilisé, appelé « Executable and Linkable Format » (ELF), devient de plus en plus populaire ce qui pourrait résulter en une meilleure compatibilité entre des applications compilées à l'aide de compilateurs différents et qui utilisent ce format par défaut. Cependant, il y a toujours un risque que quelqu'un compile le plugin avec un compilateur différent et que l'interface binaire de l'application soit logée ailleurs que dans l'application.
    On est en 2015, il y a encore des unix non elf, sérieusement ? Sinon, elf et abi sont deux choses différentes. Les incompatibilités entre compilos viennent plutôt du name mangling (et ça concerne surtout visual en fait, à ma connaissance il n’y a que deux façons de faire du name mangling, la manière microsoft et la manière intel – utilisée par gcc).

    Je passe sur le troll python/js tellement il est énorme . S’agissant d’une traduction, je comprends que ça soit laissé en l’état.


    Sinon, au vu du titre, je m’attendais à un article traitant beaucoup plus de conception. Un meilleur titre aurait été « Introduction à la programmation d’applications extensibles en C++ ».

  5. #5
    Expert confirmé
    Citation Envoyé par white_tentacle Voir le message
    Je passe sur le troll python/js tellement il est énorme . S’agissant d’une traduction, je comprends que ça soit laissé en l’état.
    Ça et le fait de ne même pas mentionner Lua, ça rend l'article assez "suspect" : tellement orienté qu'on se demande si quelque chose est vrai dedans ou si c'est juste un regroupement d'avis persos.

  6. #6
    Membre éprouvé
    La meilleure solution est d'utiliser un des langages interprétés.
    Vraiment ? Créer un tutoriel sur comment créer les plugins et ne même pas aborder la technique qui permet de s'affranchir des ABI est un peu limite. extern "C", qui permet de s'affranchir des problèmes de compatibilités entre compilateurs, est quand même une solution largement employée en développement.

  7. #7
    Membre éclairé
    Dans la première partie:
    Code C :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    extern "C" double multiply(double a, double b)
    {
      return a * b;
    }
     
    extern "C" const char * getName()
    {
      return "multiplication";
    }

    Là, le loadModule il va pas aimer. Il faudrait return "multiply".

    J'ai trouvé l'intro et la première partie intéressants, on a des exemples de code. Je ne connaissais pas cette méthode.

  8. #8
    Membre éprouvé
    En effet, j'avais pas vu la première partie. Il ne revient cependant pas suffisant sur les conséquences de l'extern "C".

    - Il faut déclarer les fonctions en extern "C" dans l'interface mais aussi dans l’implémentation (sinon la fonction sera exportée sous son nom C++ et ne sera pas trouvée par dlsym). En clair, cela revient à ne pas oublier d'inclure le header dans le fichier d'implémentation.
    - la signature de la fonction se limite à son nom. Donc deux fonctions ne peuvent plus être différenciées par leurs paramétrés.
    - deux fonctions de même noms dans deux namespaces différents correspondent à la même fonction.

    Et bien d'autres pièges qu'il aurait été bon de décrire.

  9. #9
    Responsable 2D/3D/Jeux

    Merci bredelet
    C'était une erreur provenant de la version française. Je suis désolé pour ce désagrément et cela est maintenant corrigé grâce à vous
    Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  10. #10
    Membre éclairé
    Pas de problème

###raw>template_hook.ano_emploi###