Je pense que je n'avais pas ajouté de simples parenthèses, en fait. La mémoire... ça remonte ce truc :)
Me semble qu'en fait, j'avais lu quelque part que, dans le cas ou les paramètres contiennent des appels à des fonctions, alors ces fonctions sont évaluées dans l'ordre, que la fonction soit inlinée ou pas, et j'avais donc utilisé cette méthode (je ne sais pas pourquoi j'ai pensé aux parenthèses, l'autre jour, mais bon, c'est un code d'il y à 2 ans et impliquant un langage que je préférerait oublier). Le résultat est alors devenu cohérent sur les 2 compilateurs que j'utilisais: G++ (quoique j'utilisais peut-être déjà clang++, je ne sais plus) sous Debian testing, et visual studio 2008 (je sais, c'est un IDE, mais je connais pas le nom du compilo sous jacent).
Franchement, d'ordinaire, je ne me serais pas amusé à faire ce genre de trucs casse-gueule, de la même façon que d'habitude, j'évite les macros comme la peste. Dans le cas que j'ai cité, j'ai utilisé de façon assez massive des macros, et en un endroit cette chose, en combinaison avec des macros qui résultaient en ces fameux appels, justement.
L'idée était relativement simple (tout ce que je dis est un souvenir d'il y à 2 ans, je préviens. Depuis, j'ai dormi pas mal...):
Le langage powerbuilder se base sur une sorte de machine virtuelle, de la même façon que Java, et expose une API C++ assez mal fichue selon moi à l'époque (bien que maintenant je comprenne un peu plus les raisons, mais je pense toujours que c'est améliorable).
Cette API permets, malgré tout, de pouvoir "injecter" du code: ajouter des classes, en fait, appelables ensuite depuis un programme PB classique comme si les classes en question étaient codées en PB.
Par contre, côté code natif, c'était assez pénible: des chaînes de caractère à passer 3 fois à divers moments de l'init, une visibilité nulle quant à pourquoi le code sigsegv, et pour récupérer les valeurs reçues lors d'un appel d'une méthode par PB, il fallait écrire, pour chaque argument, un truc de ce genre (dans le genre, donc pas exactement, j'ai un très gros doute pour le type): "pbvm->arg(5)->get_int(x);" et bien sûr, ça pouvait encore planter parce que si on se trompait de type, ça crashait sans dire pourquoi, lors de l'appel par la pbvm.
Donc, j'avais fait une surcouche à cette API, qui permettait de pouvoir injecter des classes en faisant dans une classe "proxy" (le terme n'est pas exact) un simple héritage d'une part d'une classe de ma surcouche, et d'autre part de la classe C++ qui fait réellement le boulot (histoire de pouvoir vérifier sur une plate-forme non windows que ça compile/marche, sans avoir besoin de devoir accéder à la PBNI --l'API powerbuilder-- ).
Dans cette classe proxy, au début, il fallait au minimum autant de lignes de code par méthode que d'arguments powerbuilder, ce qui était lourd et générateur d'erreur.
Donc, vu que j'avais un peu de temps, j'ai essayé (et réussi, même si je n'était pas vraiment très fier de la propreté du code de cette partie de ma surcouche) de faire une sorte de langage basé sur les macros du C qui permette de réduire tout le boilerplate de chaque méthode rendue accessible à 1 ligne: la ligne de déclaration de boilerplate.
Genre:
#include "npbni.hpp" // ma surcouche#include "foo.hpp" // la classe qui fait le véritable tafclasspb_foo:publicfoo,publicnpbni<NON_VISUAL_PNBI>// on pouvait exporter 2 types de classes, à la mécanique sous-jacente légèrement différente, donc template pour pas que ce soit trop pénible{RETURN_INTfoo(TYPE_FLOAT,TYPE_INT,TYPE_STRING);};
Je ne me souviens pas exactement des noms et du fonctionnement des macros, c'est juste pour donner un ordre d'idée.
[^] # Re: En vrac
Posté par freem . En réponse au journal Pourquoi empaqueter KDE prend-il du temps ?. Évalué à 2.
Je pense que je n'avais pas ajouté de simples parenthèses, en fait. La mémoire... ça remonte ce truc :)
Me semble qu'en fait, j'avais lu quelque part que, dans le cas ou les paramètres contiennent des appels à des fonctions, alors ces fonctions sont évaluées dans l'ordre, que la fonction soit inlinée ou pas, et j'avais donc utilisé cette méthode (je ne sais pas pourquoi j'ai pensé aux parenthèses, l'autre jour, mais bon, c'est un code d'il y à 2 ans et impliquant un langage que je préférerait oublier). Le résultat est alors devenu cohérent sur les 2 compilateurs que j'utilisais: G++ (quoique j'utilisais peut-être déjà clang++, je ne sais plus) sous Debian testing, et visual studio 2008 (je sais, c'est un IDE, mais je connais pas le nom du compilo sous jacent).
Franchement, d'ordinaire, je ne me serais pas amusé à faire ce genre de trucs casse-gueule, de la même façon que d'habitude, j'évite les macros comme la peste. Dans le cas que j'ai cité, j'ai utilisé de façon assez massive des macros, et en un endroit cette chose, en combinaison avec des macros qui résultaient en ces fameux appels, justement.
L'idée était relativement simple (tout ce que je dis est un souvenir d'il y à 2 ans, je préviens. Depuis, j'ai dormi pas mal...):
Le langage powerbuilder se base sur une sorte de machine virtuelle, de la même façon que Java, et expose une API C++ assez mal fichue selon moi à l'époque (bien que maintenant je comprenne un peu plus les raisons, mais je pense toujours que c'est améliorable).
Cette API permets, malgré tout, de pouvoir "injecter" du code: ajouter des classes, en fait, appelables ensuite depuis un programme PB classique comme si les classes en question étaient codées en PB.
Par contre, côté code natif, c'était assez pénible: des chaînes de caractère à passer 3 fois à divers moments de l'init, une visibilité nulle quant à pourquoi le code sigsegv, et pour récupérer les valeurs reçues lors d'un appel d'une méthode par PB, il fallait écrire, pour chaque argument, un truc de ce genre (dans le genre, donc pas exactement, j'ai un très gros doute pour le type): "pbvm->arg(5)->get_int(x);" et bien sûr, ça pouvait encore planter parce que si on se trompait de type, ça crashait sans dire pourquoi, lors de l'appel par la pbvm.
Donc, j'avais fait une surcouche à cette API, qui permettait de pouvoir injecter des classes en faisant dans une classe "proxy" (le terme n'est pas exact) un simple héritage d'une part d'une classe de ma surcouche, et d'autre part de la classe C++ qui fait réellement le boulot (histoire de pouvoir vérifier sur une plate-forme non windows que ça compile/marche, sans avoir besoin de devoir accéder à la PBNI --l'API powerbuilder-- ).
Dans cette classe proxy, au début, il fallait au minimum autant de lignes de code par méthode que d'arguments powerbuilder, ce qui était lourd et générateur d'erreur.
Donc, vu que j'avais un peu de temps, j'ai essayé (et réussi, même si je n'était pas vraiment très fier de la propreté du code de cette partie de ma surcouche) de faire une sorte de langage basé sur les macros du C qui permette de réduire tout le boilerplate de chaque méthode rendue accessible à 1 ligne: la ligne de déclaration de boilerplate.
Genre:
Je ne me souviens pas exactement des noms et du fonctionnement des macros, c'est juste pour donner un ordre d'idée.