Le topic de la programmation: Et envoyez des sioux!

[Tramb]

Non mais "mieux" niveau sécurité, y a pas à "attendre un moment". Y a Ada depuis 83, Common Lisp depuis 84 et Rust maintenant par exemple.

[gros_bidule]

Tiens, sans arrière pensée, si la sécu est un soucis amoindri par le code managé, pourquoi fait-on encore du C, C++ etc ?
Biensur, des besoins de très haute perf, d'embarqué ou de contrôle peuvent justifier l'usage de ces langages, mais dans les autres cas ? Pourquoi s'embêter ?
Il n'y a pas des outils qui vont quand même offrir la sécu, par exemple avec des sandbox ?

Je dis cela car un truc qu'on me disait souvent en C++, c'est que devant gérer la mémoire à la main, tu vas faire davantage de fuites mémoire qu'en Java (GC oblige). Seulement voilà, en C++ tu as des libs qui offrent des garbage collectors, rien ne te force à tout faire à la main, tu fais ce que tu veux. J'imagine qu'en C, C++ etc, vous avez bien des trucs pour la sécu qu'on retrouve dans les langages voués à être managés ? Ou bien est-ce peu populaire car vous perdriez en efficacité sur dans des domaines clefs ? L’écosystème est plus intéressant dans vos branches ?

[Anonyme20240202]

En C++ moderne y'a aucune gestion de mémoire à la main à proprement parler, mais bon on risque de rentrer dans une discussion pas très constructive à ce sujet, car oui, effectivement, rigoureusement parlant le langage en lui même ne dit rien à ce sujet (pour le moment...).

Mais en gros ta mémoire est libérée en sortie de scope donc c'est:

{ // début du scope
    ressource
} // fin du scope

Quand tu sors du scope la mémoire est dispo. Et hors du scope la ressource n'est plus accessible.

Pour le C c'est une autre histoire, et effectivement on peut parler de gestion "à la main". Mais ce n'est qu'un peu de rigueur, rien d'insurmontable, surtout que c'est pas non plus compliqué à tester comme on le disait plus haut (sanitizer, ou juste de bêtes tests).

Après ta question est un peu biaisée car de mon point de vue, si je fais un projet perso simple, pourquoi j'irai m'embêter avec un truc managé. Avec C et C++ sur n'importe quelle machine de n'importe quelle époque, tu me files un compilateur et paf je te programme un truc rigolo. Alors que déployer du Java ou Python sur telle ou telle plateforme j'ai aucune idée de comment faire (fin j'exagère, suffit d'installer la jvm et voilà), dans le sens où il va falloir vérifier le support, etc. Sachant qu'en soit, un bug ou un crash n'est pas nécessairement un problème, selon tes besoins (genre si c'est juste un petit projet perso).

Mais ouais, c'est l'ecosystème avant tout. C'est toujours ce qui dictera la popularité de tel ou tel langage en gros.

Mais sinon je vais te donner un exemple qui est arrivé en production là où je bossais:

On avait une application haute fréquence, gros volumes de données. Et en gros on foutait dans un "n-cube" (cube à n dimensions, tout un tas de vecteurs quoi) toutes les données qui arrivaient. Et bref c'était en RAM tout ça (in-memory database), donc rapide d'accès etc.

Niveaux langages on avait:

Le C++ pour la partie calculatoire pure
C# pour les interfaces utilisateurs et autres trucs (bus de communications)
Java pour la fameuse in-memory database présentée au dessus.

Et bien l'élément foireux quand j'étais là, c'était la partie Java. Car le GC intervenait de la mauvaise manière concernant les besoins, en gros la mémoire s'accumulait longtemps, puis paf, le GC arrivait pour dégager tout ça (je suis pas un expert sur l'implémentation des GCs) mais en gros la conséquence c'est qu'on avait des pics de latence réguliers quand le gros lard de GC se ramenait pour nettoyer le bazar accumulé.

Et donc c'était un énorme problème de "sécurité" car vu que c'tait des systèmes hyper sensibles à la latence, c'était véritablement hyper critique d'avoir de tels pics de latence. En gros ça serait l'équivalent de ton pare brise qui devient totalement noir pendant 1 seconde alors que t'es à fond sur l'autoroute.

Donc là (bon encore une fois j'y connais rien en Java) mais t'as un problème qui est lié/dépendent de l'implémentation sous jacente du GC. Comment maintenant tu forces le GC à agir comme tu le souhaites?

Alors je sais que y'a des trucs du genre appeler le GC à la main ou autre (qui est une bad practice apparemment), mais on voit bien que le langage ne te sauve pas. Et les deux ingés qu'on avait sur le sujet se sont cassés la tête dessus pendant 6 mois ou un truc du genre

Faut faire les choses bien et généralement le langage ne pourra pallier qu'assez peu quant à ce que tu veux faire concrètement. Le langage ne se soucie pas des abstractions plus haut niveau que tu crées via son utilisation. Parfois un peu quand même, car des constructions tellement courantes telles que les tableaux/matrices/vecteurs/listes/Tree/hashmap etc. font parties même du langage, mais le langage va naturellement s'arrêter à un niveau d'abstraction assez bas.

Là interviennent les librairies ou autres outils externes

- - - Mise à jour - - -

Donc ouais on peut dire qu'utiliser un autre langage managé est une solution, par certains aspect.

Mais tout simplement utiliser l'écosystème moderne pour d'autres langages "non managés" est relativement équivalent

(Sinon ouais le Kernel Linux est en C et tout un tas de trucs sont en C car le langage est "gelé" dans le temps, les specs sont claires et figées et y'a tout l'historique, donc on reste avec ça. T'es à peu près sûr que quelque soit le micro processeur/micro controlleur ou tout ce que tu veux, tu pourras faire écrire ton truc en C et le compiler pour cette plateforme)

[Rao]

Cette histoire de garbage collector qui vient ponctuellement impacter les perfs ça ressemble à ce qu'ils ont eu chez discord et qui explique pourquoi ils ont switché un des éléments de leur chaine depuis Go (avec GC) vers Rust (pas de GC).
https://blog.discord.com/why-discord...t-a190bbca2b1f

[gros_bidule]

Thx !

[Anonyme20240202]

Ah très intéressant cet article Rao, effectivement ça ressemble beaucoup à la situation qu'on avait avec la partie Java.

Après je suis pas sûr d'avoir compris pourquoi Discord gère le read state server-side, p'têt pour te permettre de conserver ça d'une machine à une autre, mais même là je vois pas le souci niveau latence en faisant ça tranquillement côté client et en transférant ponctuellement l'état total lors de la co', 'fin bref me manque p'têt des infos.

[Rao]

Après en java du moins, il y a plusieurs implémentations de GC et dans une certaine mesure ça se tune , même si effectivement on ne peut pas faire l'impasse dessus

[Teocali]

Après en java du moins, il y a plusieurs implémentations de GC et dans une certaine mesure ça se tune , même si effectivement on ne peut pas faire l'impasse dessus

This.

Le problème que Kamimaze rencontrait n’est pas vraiment lié au langage Java qu’à la Jvm utilisée. Je suis sûr qu’il est tout à fait possible de faire du Java sans GC

[Cwningen]

Ouais ouais on est d'accord même si l'exemple en question est très forcé, tu utilises les range ou n'importe quel algorithme de la librairie standard. T'as jamais vraiment besoin de manipuler des itérateurs.

Les ranges ne sont que des pairs d'itérateurs, le problème est le même. Si c'est "erase" qui te dérange, qu'est ce que tu pense de ça ?

std::vector v = {1, 2, 3};
std::ranges::copy(v, std::back_inserter(v));

Même si tu ne les vois pas, il y a une utilisation d'itérateur invalide et de pointeurs vers de la mémoire libérée.

[Anonyme20240202]

Euh ouais, enfin je repondais comme ça pour l'exemple ponctuel de l'itérateur, je sais même pas trop quel est le sujet. Si c'est de dire qu'on peut faire tout un tas de bêtises avec C++, aucun problème je suis avec vous.

Dans ton cas ouais y'a une erreur qui sous le capot on peut considérer liée aux itérateur, mais ça a déjà plus de sens de voir pourquoi ça fonctionne pas, t'essaye de copier avec source = dest, la doc le dit explicitement: "The behavior is undefined if result is within the range [first, last)", c'est déjà plus clair avec cette abstraction je trouve. Peu importe que ce soit implémenté avec des itérateurs ou autre, j'pense que même un débutant verra plus facilement l'erreur quand c'est écrit via cette abstraction.

Mon propos c'tait juste que je suis pas sûr quelles responsabilités on peut attribuer au langage.

Je vais dire un truc qui peut paraitre un peu idiot et exagéré mais avec n'importe quel langage informatique je peux coder un interpréteur de C++ et continuer à coder en C++ en faisant de la merde. Donc j'exagère mais on voit bien que y'a une limite à l'intervention du langage

[Tramb]

Je vais dire un truc qui peut paraitre un peu idiot et exagéré mais avec n'importe quel langage informatique je peux coder un interpréteur de C++ et continuer à coder en C++ en faisant de la merde. Donc j'exagère mais on voit bien que y'a une limite à l'intervention du langage

Mais tu n'arriveras pas à exploit une execution en ROP sur ton interpréteur C++ en <langage plus safe>.

Ah et si tu peux coder un interpréteur C++ je t'ai clairement sous-estimé parceque moi non ^^

PS: Le sujet c'est que tu disais que les scopes et la RAII et quelques "bonnes pratiques" permettaient de faire du C++ sans erreurs mémoire.
Donc on disait que pas du tout, c'est tout.

[Anonyme20240202]

Ouais ouais ok, t'es dur haha, je donne le point, j'aurais pas du dire ça. Dans mon pavé plus haut, le point principal c'tait surtout de définir la notion de vulnérabilité.

Genre quand tu contrôles un bras robotique, s'il commence à te mettre des baffes, c'est un problème de sécurité, mais quelque soit le langage que t'utilises, la notion de baffe n'existe pas, donc le langage ne te protège pas des baffes.

Après ouais j'avoue que j'aurais besoin de reflechir d'avantage, parce que t'as l'air d'entendre sécurité au sens d'un certains nombres d'éléments précis/autour d'un domaine précis comme gestion de la mémoire etc. tu parlais d'Ada, il faudrait que je relise ça et que je me renseigne plus sur Ada

Mais la gestion de la mémoire c'est quelque part une conséquence fortuite des architectures qu'on utilise, alors je joue un peu au con en disant ça, parce que j'aurais bien du mal à trouver une machine qu'utilise pas les concepts de registre etc. mais ce que je veux dire, c'est où est ce que tu t'arrêtes en terme de protection, à quel niveau d'abstraction.

Si tu cadres ça à la gestion de la mémoire, je pourrais te dire, qu'en est il de la sécurité réseau. Genre si dans ton langage y'a une abstraction réseau.

Parce que le débutant qui, à juste titre, écrit son algo en pseudo langage, il sait ce qu'il veut faire.

Donc il veut faire une multiplication de matrice, le fait est qu'il y a un impact sur la mémoire et potentiellement des failles à exploiter (overflow etc.), via cette fonctionalité/implémentation de la multiplication de matrice, mais il en est de même s'il veut envoyer un message vers un autre PC, stocker un mot de passe etc.

[Cwningen]

Dans ton cas ouais y'a une erreur qui sous le capot on peut considérer liée aux itérateur, mais ça a déjà plus de sens de voir pourquoi ça fonctionne pas, t'essaye de copier avec source = dest, la doc le dit explicitement: "The behavior is undefined if result is within the range [first, last)", c'est déjà plus clair avec cette abstraction je trouve. Peu importe que ce soit implémenté avec des itérateurs ou autre, j'pense que même un débutant verra plus facilement l'erreur quand c'est écrit via cette abstraction.

Non, c'est pas ça l'erreur. La destination est après la source et ne la recouvre pas du tout (on copie v après la fin de v). Le problème est que les itérateurs d'entrée sont invalidés quand le tableau est redimensionné.

Une version plus simple du problème (que j'aurais du utiliser mais il n'y a pas de ranges) est:

std::vector v = {1, 2, 3};
auto it = v.begin();
v.push_back(4);
utilise(*it);

Le propos était que les itérateurs (et tout ce qui en contient) doivent être manipulés avec le même soin que les pointeurs et références, ils ne te sauveront pas.

[Anonyme20240202]

Ok, bon exemple du coup vu que je me suis gourré haha, je vais revoir ça

Edit: Ah mais je suis con j'ai dit n'importe quoi, ouais c'est juste que tu modifies le conteneur pendant que tu itères dessus ouais, j'ai craqué, c'est comme std::copy, en voyant std::ranges::copy j'ai buggé. Mais ouais, rien de spéficique à un itérateur. Si on implémente ça avec des index dans un array c'est pareil, l'index courant change de sens quand tu modifies le conteneur, et est donc invalide.

Mais ouais, le compilateur dit rien et clang-tidy non plus

[Cwningen]

À plus y réfléchir, j'ai fait une erreur avec copy, parce que si on remplace le vector par une list, ça ne marche toujours pas (pour une autre raison), j'aurais du utiliser "std::copy(v.begin(), std:rev(v.end()), std::back_inserter(v));"

Pour ce qui est des compilateurs, clang experimental -Wlifetime détecte le problème du push_back mais ne le vois pas quand c'est caché dans le copy. https://gcc.godbolt.org/z/SEK2ZU

[Anonyme20240202]

Ouais ouais, d'ailleurs je viens de voir l'implémentation, c'est vraiment brutal de chez brutal, je m'attendais pas à ça.

En gros ils font texto:

void test_copy_it(
    std::vector<int>::iterator source_first,
    std::vector<int>::iterator source_last,
    std::vector<int>& destination) {
    while(source_first != source_last) {
        destination.push_back(*source_first); // iterators belonging to destination invalidated
        *source_first++; // invalid, doesn't know where to go
    }
}

Le pushback c'est un peu l'équivalent du erase (realloc), c'est juste que c'est obfusqué, parce que dans ce contexte, le source_first est global à tout, donc pas scopé. Donc quand source = dest, tu dégommes source_first lors du push back.

Le back inserter ne fait rien de spécial, c'est surtout du sucre, voilà l'équivalent:

void test_copy_it(
    std::vector<int>::iterator source_first,
    std::vector<int>::iterator source_last,
    std::back_insert_iterator<std::vector<int>>& destination) {
    while(source_first != source_last) {
        destination = *source_first; // iterators belonging to destination invalidated
        *source_first++; // invalid, doesn't know where to go
    }
}

Donc pour moi c'est un peu comme le fait que le destructeur (équivalent erase) soit appelé lors d'une assignation pour une instance unique.

#include <iostream>
#include <memory>

class Example {
  public:
    explicit Example(std::string& owned) : owned(owned) { }
    void use() { std::cout << owned << std::endl; }
    ~Example() {
        owned = "invalid";
        std::cout << "Destroyed" << std::endl;
    }
  private:
    std::string& owned;
};

int main() {
    std::string danger = "danger";
    auto instance = std::make_unique<Example>(danger);
    std::string another = "another";
    instance = std::make_unique<Example>(another); // destructor is called
    std::cout << danger << std::endl;
    
}

Je sais pas quelle est la conclusion de tout ça, j'ai limite envie de dire que std::copy (ou std::ranges::copy) est pas clair, parce que ça tripote les paramètres d'entrée de la source finalement, ce qui n'est pas intuitif, p'têt plus performant (bien sûr). Perso ça me parle pas en tant qu'utilisateur

void test_copy_it_safe(
    const std::vector<int>& source,
    std::vector<int>& destination) {
    if(source == destination) { return; }
    auto begin = source.begin();
    auto end = source.end();
    while(begin != end) {
        destination.push_back(*begin++);
    }
}

Et voilà, la fonction est bien plus belle

Je déconne c'est dégueulasse mais je crois que la signature de la fonction de base me dérange tout simplement. Enfin bref, perso je réflechis jamais en terme d'itérateur, je pense à l'algo que je veux faire en pseudo langage, ce qui est peut-être une faute pour quelqu'un qui fait du C++.

Si on m'avait demandé, genre lors d'un entretien, d'implémenter une copie de vecteur à lui-même, je pense que je serais parti sur du resize puis du copy, voire juste un truc bête sans rien vous cacher:

#include <vector>

void copy_dummy(const std::vector<int>& source, std::vector<int>& destination) {
    auto copy{source};
    destination.insert(destination.end(), copy.begin(), copy.end());
}

int main() {
    std::vector<int> j{1, 2, 3};
    copy_dummy(j, j);
}

Mais maintenant que j'y pense, et suite à ta remarque sur les listes, c'est le push back qui me parait dégueu, pourquoi réallouer, y'a pas plus beau comme implém' (small buffer optimization au moins, mais ouais, veulent de la mémoire contigue donc realloc)? M'enfin j'imagine que les mecs qui ont fait la lib savent ce qu'ils font et qu'on est surtout en train de malmener le vector pour rien. Un peu artificiel p'têt comme cas, faudrait que j'y reflechisse

[Thamior]

En C++ moderne y'a aucune gestion de mémoire à la main à proprement parler, mais bon on risque de rentrer dans une discussion pas très constructive à ce sujet, car oui, effectivement, rigoureusement parlant le langage en lui même ne dit rien à ce sujet (pour le moment...).

Mais en gros ta mémoire est libérée en sortie de scope donc c'est:

{ // début du scope
    ressource
} // fin du scope

Quand tu sors du scope la mémoire est dispo. Et hors du scope la ressource n'est plus accessible.

Je ne suis pas sur de bien comprendre ton propos. Certes le scoping fonctionne comme tu le décris, mais on gère bien la mémoire à la main lorsqu'on fait de l'allocation dynamique ou lorsqu'on utilise des itérateurs/références/pointeurs, non? C'est pas parce que ça se déclare comme du C++ moderne qu'au final ça n'est pas un pointeur légèrement glorifié (std::unique_ptr je te regarde).

[TarteAuxFleurs]

Tiens, sans arrière pensée, si la sécu est un soucis amoindri par le code managé, pourquoi fait-on encore du C, C++ etc ?
Biensur, des besoins de très haute perf, d'embarqué ou de contrôle peuvent justifier l'usage de ces langages, mais dans les autres cas ? Pourquoi s'embêter ?
Il n'y a pas des outils qui vont quand même offrir la sécu, par exemple avec des sandbox ?

Je dis cela car un truc qu'on me disait souvent en C++, c'est que devant gérer la mémoire à la main, tu vas faire davantage de fuites mémoire qu'en Java (GC oblige). Seulement voilà, en C++ tu as des libs qui offrent des garbage collectors, rien ne te force à tout faire à la main, tu fais ce que tu veux. J'imagine qu'en C, C++ etc, vous avez bien des trucs pour la sécu qu'on retrouve dans les langages voués à être managés ? Ou bien est-ce peu populaire car vous perdriez en efficacité sur dans des domaines clefs ? L’écosystème est plus intéressant dans vos branches ?

Tu as parlé de programmation système, mais de manière plus général il y a de nombreux composants logiciels qui gagnent beaucoup à être optimisé.
Typiquement, tout logiciel visant à être répandu (moteur de BDD, serveur web, la JVM, etc.) peut valoir le coup d'être programmé dans un langage qui offre de bonnes performances si c'est pour être déployé sur de nombreuses machines.

- - - Mise à jour - - -

Je ne suis pas sur de bien comprendre ton propos. Certes le scoping fonctionne comme tu le décris, mais on gère bien la mémoire à la main lorsqu'on fait de l'allocation dynamique ou lorsqu'on utilise des itérateurs/références/pointeurs, non? C'est pas parce que ça se déclare comme du C++ moderne qu'au final ça n'est pas un pointeur légèrement glorifié (std::unique_ptr je te regarde).

Je suis d'accord avec toi dans le sens où en C++ moderne tu as quand même des problématiques de mémoire que tu n'as pas dans les langages avec ramasse-miettes.
Par exemple, il y a toute la notion d'ownership qui te contrains à mettre en place des arbres à base de unique_ptr, shared_ptr, et weak_ptr alors qu'en Java tu n'as pas ces problématiques. De même, la notion de pile et de tas est centrale ce qui n'est pas le cas des langages à ramasse-miettes.

Enfin il y a toutes les bêtises que tu peux faire si tu ignores le modèle de mémoire de C++ et dont Cwningen parlait sur la page d'avant :

N'importe quoi qui contient un pointeur/référence emprunté est dangereux : itérateurs, vues (string_view, span, match_results, ...), lambdas avec capture par référence, ... C'est plus simple d'utiliser un borrow checker que de se priver de tout ça.

- - - Mise à jour - - -

Mais maintenant que j'y pense, et suite à ta remarque sur les listes, c'est le push back qui me parait dégueu, pourquoi réallouer, y'a pas plus beau comme implém' (small buffer optimization au moins, mais ouais, veulent de la mémoire contigue donc realloc)? M'enfin j'imagine que les mecs qui ont fait la lib savent ce qu'ils font et qu'on est surtout en train de malmener le vector pour rien. Un peu artificiel p'têt comme cas, faudrait que j'y reflechisse

Je ne suis pas sûr de très bien comprendre ta phrase, donc je suis peut être à côté de la plaque. Lais si la mémoire que tu utilises pour stocker les données du vecteur est pleine lors du push_back (len==size), bah faut allouer un plus gros bout pour pouvoir stocker la nouvelle entrée et ça ne sera pas forcément à la suite.
De même, on veut de la mémoire contiguë parce que ça permets une structure de donnée simple et légère (ptr, len, size).

[Tramb]

Pour être clair, tu as quand même des soucis si tu ne penses pas à l'ownership dans un langage garbage-collecté
C'est juste que ça sera des soucis de perf, ou des crashes si ça leake trop, ou des bugs sémantiques si tu fais du use-after-finalize, mais ça évite quand même les bugs mémoire dont FF et google nous disent qu'ils représentent une grosse part des vuln.

[sosoran]

Bonjour bonjour, je me suis dit que ce serait drôle de partager ma situation actuelle ici :

Alors je sors d'une formation de bioingénierie. On avait fait un peu de C++, les bases, mais c'est tout. Là je viens de commencer un stage dans une start-up qui s'occupe de créer des systèmes de compression pour données issues de séquencages génomiques.
je m'occupe de faire des wrapper d'un langage à l'autre en gros: l'idée c'est d'encapsuler le code source par une enveloppe qui permet d'accéder aux fonctions de bases depuis un autre langage.
J'ai commencé par wrapper le niveau applicatif de la technologie d'encodage/décodage, écrite en C, vers C++. C'était un peu la galère pour le novice que j'étais ( et que je suis d'ailleurs toujours ), mais c'était assez fun d'essayer d'adapter tout ça. Du coup les structures qui se retrouvent appelées dans beaucoup de fonctions deviennent des classes à part entières, et à des moments je me retrouvais avec structures mallocée contenant des pointeur callocé vers des array d'instances newées avec des casts a mettre un peu partout et une shitload de goto et de macros a gérer. La gestion de la mémoire devenait un vrai casse-tête .

Finalement j'ai réussi à rendre ce truc au bout de 4 mois, dans une version fonctionnelle .

Ensuite on m'a demandé de faire pareil avec Python. J'ai commencé le bousin en utilisant CTypes, mais j'ai été arrêté en pleine course par un changement de priorité : il fallait un wrapper java pour pouvoir faire une intégration du code dans une application mobile android.

Du coup, je me suis lancé dans JNI (Java Native Interface), librairie censée permettre l'exposition de variable et fonctions de C vers Java et inversement. C'est honnêtement une m**** sans nom: à chaque ligne de code il en faut 10 de plus pour le supporter et c'est plutôt difficile à comprendre. Et chaque structures, enum ou type un peu trop custom devient une classe à gérer, avec toutes ces histoires de package et import. Bref c'est complexe .

Et actuellement j'en suis encore là-dessus, on va pas atteindre notre deadline mais c'est pas très grave. L'avantage c'est quand même que je travaille avec une équipe ultra chouette ( et y'a du café gratuit, et je peux travailler autant que je veux à la maison plutôt qu'au bureau, et je peux les crouler de questions sans que ca pose problème), et qu'à toucher a autant de truc à la fois, j'ai l'impression de progresser à vitesse grand V, ce qui est plutôt satisfaisant ( pour résumer, C, C++, Python et Java, en 4 mois, et je ne connaissais que la base de C++ au tout début).

Voilà voilà

[Cwningen]

Pour le python et java, je comprends, mais pour le C++, c'est vraiment utile des wrappers aussi complexes alors qu'on peut appeler les fonctions C directement ? C'était pour profiter de certaines fonctionnalités du C++ comme les templates ?

[sosoran]

Pas vraiment malheureusement, l'idée c'était vraiment de pouvoir dire à quelqu'un qui connaît que le C++ et pas le C : " tiens, voilà tes classes dont tu connais bien le fonctionnement, et les fonctions qui vont bien, fais-en ce que tu veux, on te garantit un résultat similaire et tu n'as pas besoin de t'embêter avec des structures et la gestion de la memoire avec malloc etc"
... je peux pas te dire que ce soit absolument le truc le plus pertinent à faire, mais c'est ce dont y'avait besoin et qui m'étais demandé..

[Teocali]

Putain , JNI... je compatis mais tellement fort.

Surtout que pour Android, tu as le NDK qui te permet de dev en c/c++

[sosoran]

Putain , JNI... je compatis mais tellement fort.

Surtout que pour Android, tu as le NDK qui te permet de dev en c/c++

ouais mais dès que ca monte un poil en complexité faut repasser par jni de toute facon si j'ai bien compris la chose

[gros_bidule]

Plutôt que JNI, peux-tu passer par JNA ? C'est parfois moins performant, mais c'est plus simple.

[BentheXIII]

En ce qui concerne le wrapping de C++ avec Python, je suis tombé amoureux de Pybind

[sosoran]

Plutôt que JNI, peux-tu passer par JNA ? C'est parfois moins performant, mais c'est plus simple.

malheureusement pas, la performance est plutot importante pour notre cas. les volumes de données à traiter peuvent cumuler les Giga-octets, et à traiter ca demande de la puissance :/

"En ce qui concerne le wrapping de C++ avec Python, je suis tombé amoureux de Pybind"

Alors je t'avoue que j'était parti pour utiliser CTypes, mais je vais jeter un coup d'oeil à ça.

[BentheXIII]

J'ai essayé maintes fois de me mettre au wrapping Python/C++, et j'ai été autant de fois rebuté par la doc, la verbosité, ou l'incompatibilité avec certaines des librairies C++ que j'utilisais.

Pybind supporte quasiment tous les types de la librairie Eigen par défaut (conversion automatique entre les types numpy et Eigen côté C++), et n'est pas si verbeux que ça. Les exemples fournis sont suffisamment utiles pour servir de base à des trucs plus compliqués, et les seules trucs un peu bloquant que j'ai rencontré (définition des bindings vers des membres ou des méthodes statiques, ou bien la nécessité de créer des bindings particuliers pour des classes virtuelles) sont documentés soit en creusant un peu la doc, soit en allant sur le forum de discussion de Pybind qui m'a l'air assez actif

[rOut]

J'ai pas trop utilisé mais je sais que pas mal de projets utilisent SWIG pour wrapper du code C/C++ vers plein d'autres langages (Python et Java entre autres). J'avais testé vite fait et ça avait l'air de bien fonctionner et assez facilement, même avec des classes C++.

[sosoran]

Je note Pybind alors, merci pour le conseil, ca pourrait m'être vraiment utile .

Après ca fait un moment que j'ai mis ce projet de côté, je ne me rappelle plus vraiment des raisons qui ont motivé le choix de CTypes par rapport aux autres.



... j'ai aussi l'impression que ce que je fais dépasse de loin le cadre d'un truc à donner normalement à un stagiaire, mais difficiel de savoir si l'impression est légitime ou non