Discussion :

[LittleWhite]

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

[LittleWhite]

Voici la première partie.

Bonne lecture.

[LittleWhite]

Et la seconde partie :

Bonne lecture.

[white_tentacle]

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

[Iradrille]

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.

[fenkys]

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.

[bredelet]

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.

[fenkys]

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.

[LittleWhite]

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

[bredelet]

Pas de problème