• [^] # Re: Donc pour résumer...

    Posté par . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 2.

    mais j'ai de plus en plus tendance à passer à Python+PyQt pour les GUI et interfacer avec un backend à plus hautes performances.

    Je comprend.

    On ne pourra pas passer par du C++ (ou n'importe quel autre langage qui utilise autre chose que pointeurs + types machines) tant qu'une ABI n'aura pas été définie ;

    Sauf que ce bout de code:

    struct foo
{
 int* ptr;
};
foo foo_make( void )
{
 foo f; f.ptr = 0;
 return f;
}

    C'est du C++ parfaitement valide. L'ABI est stable, bien que j'aie un doute sur le fait que ce soit par convention ou par standard.
    Le fait est que, bien sûr, il faut se débarasser de la totalité des fonctionnalités C++ dans l'API, mais bon... je pinaille, j'avoue :)
    En tout cas, j'en retire que ce que tu fais avec python+rust, tu peux le faire avec python+C++.

    En ce qui concerne Rust, il a une FFI plutôt correcte avec le C

    Je ne suis pas expert, mais j'ai l'impression que c'est un peu la meme chose partout, de ce point de vue la. Enfin, non, puisqu'en C++, justement, il n'y a pas besoin d'autant de colle.
    Objectivement, je dirais avantage à C++ en terme de quantité de code vital pour importer du code C, et pour cause, un sous-ensemble du C++ est entièrement compatible avec le C (mais pas l'inverse, parce qu'il me semble que le C++ réserve certains mots non réservés par le C, genre public).

    Enfin, ce genre de trucs me rappelle la fois ou j'avais du interfacer du C++ avec powerbuilder12... j'avais fini par pondre un wrapper complet, qui permettait avec quelques macros (non nécessaires elles, mais ça réduisait méchamment le boilerplate) et beaucoup de template, histoire d'etre sur que quand ça plantait ça venait pas de la colle powerbuilder/C++... foutu langage proprio de merde, si tu veux mon avis.