Version imprimable
Hello,
Que me conseilleriez vous pour faire une appli interrogeant une database ("postgres" ou "oracle"). L'aspect multiplateforme est important, au minimum windows et mac. Autre point important est que je ne veux pas d'install, l'application doit pouvoir s'installer de facon "portable" (juste en copiant un dossier).
JavaFX ou QtQuick?
JDBC me parait etre l'argument essentiel dans le choix de Java,
Et la recompilation me parait en la defaveur de Qt.
Qu'en pensez-vous?
<troll>Une application Java nécessite l'installation d'une JVM, ce qui nécessite de télécharger un fichier de plusieurs centaines de Mo. Si tu fournis les sources de ton programme C++/Qt, tu n'auras qu'un dossier à partager...</troll>
Les contraintes dont tu parles (recompilation, installer) sont des détails, qui nécessite juste de mettre en place les outils de production adéquats. Ce n'est pas ce qui devrait déterminé le choix du langage.
je ne pense pas que la taille de la JVM soit cruciale dans le choix de la techno.
l'avantage de la JVM par exemple est d'avoir mon programme (closed source) pouvant marcher sur linux, contrairement à Qt où il y aura beaucoup plus de travail pour deployer l'appli.
Je pensais plus à la rapidité de l'interface JavaFX vs QtQuick?
est ce que Java produit toujours des impressions de lenteur?
est-ce que QtQuick est assez mature pour le Desktop?
Est-ce que QtQuick utilise beaucoup de CPU? (comme c'est basé sur JS et une machine virtuelle V4)
Certain n'aime pas avoir une JVM qui tourne en permanence sur leur ordi et qui l'installe pas ou ne la lance pas automatiquement.Citation:
Envoyé par epsilon68
Mais effectivement, c'est le problème de l'utilisateur, s'il en veut pas installer une JVM et qu'un programme est écrit en Java, il passe son chemin.
Non, sauf cas particulier où tu utiliserais des fonctionnalités spécifiques à Linux/Windows (par exemple, si tu appelles un QProcess pour lancer un script bash - mais le problème sera identique pour un programme Java), le code C++/Qt est parfaitement portable.Citation:
Envoyé par epsilon68
Une différence quand même est qu'il faut effectivement compiler deux fois ton application (pour Linux et Windos), ce qui nécessite d'installer les 2 OS. Mais :
1. il serait idiot de distribuer une application Java qui n'a pas été testé sur l'un des environnements, donc même avec Java, tu as besoin des 2 OS.
2. la compilation nécessite juste d'ouvrir le projet dans QtCreator et lancer le build. Et cela doit être fait qu'une seule fois, lorsque l'on distribue la version finale (ou à chaque fois que l'on fait une build stable si on fait des tests). Si cela prend trop de temps, on fait un serveur de build
Dans tous les cas, l'installation d'un environnement de build professionnel, que ce soit pour Java ou C++/Qt, nécessite un peu plus de choses que d'installer un simple IDE. Les outils sont pas les mêmes (bien que, j'utilise Jenkins pour mes projets C++/Qt), mais au final, ce n'est pas cela qui doit orienter le choix.
J'utilise yEd, qui est un éditeur de graphe écrit en Java et je ne trouve pas lent (je ne sais pas si c'est du JavaFx... Java a changé tellement souvent de lib graphique que je ne sais plus laquelle est recommandée actuellement)Citation:
Envoyé par epsilon68
Donc Java peut être suffisamment rapide, s'il est bien codé.
Qt Quick est sorti depuis quelques années, donc je dirais que oui.Citation:
Envoyé par epsilon68
En particulier, il y a des tables view, ce qui est probablement ce que tu utiliseras pour afficher tes données.
Par contre, tu auras quand même du code C++ à écrire (pour la connexion à la base de données, probablement)
Ta question est étrange, puisque tu compares QtQuick et Java, qui utilisent tous deux une VM. (et en fait, QtQuick n'utilise pas une VM, mais compile à la volée avec un JIT... comme Java)Citation:
Envoyé par epsilon68
Qt Quick est optimisé pour tourner sur mobile, donc optimisée pour ne pas exploser le CPU, la RAM et les performances.
Par contre, il est justement optimisé niveau graphique pour être efficace (utilisation de l'accélération matérielle via OpenGL), ce qui nécessite plus de boulot de préparation (en interne) que QtWidget et donc une utilisation mémoire plus importante. Mais on gagne en termes de performances.
Mais encore une fois, cela n'a pas de sens de comparer QtQuick seul, il faut le comparer avec JavaFx. QtQuick consomme du CPU, mais est-ce que c'est plus que l'équivalent avec JavaFx ?
Et même cette question n'est pas forcement pertinente. La question n'est pas de savoir qui est le meilleur sur chaque point particulier, mais de savoir si chaque approche repond aux contraintes minimales de ton projet. Si c'est le cas, alors tu dois choisir sur d'autres critères. (si QtQuick consomme plus de CPU que JavaFx dans l'absolue, mais que le premier consomme 1.1% de CPU et le second consomme 1.0%, est-ce que c'est pertinent de choisir l'un ou l'autre selon ce critère ?)
QtQuick utilise la VM V4 depuis peu, et non plus V8.Citation:
Envoyé par mintho carmo
V4 fait du JIT, comme Java VM aussi, mais elle reste indispensable pour executer QtQuick.
est-ce que QtQuick ne consomme que 1%? et JavaFX aussi?Citation:
Envoyé par mintho carmo
c'est ce genre d'info et de retour d'expérience que je recherche pour aiguiller mon choix.
maintenant, mon choix se porterait plus sur Java, mais la lenteur que j'avais observée en swing en java 1.4 (il y a quand meme longtemps) serait définitivement l'argument contre Java.
Comme tu dis, ca depend de comment on code, mais ca serait bien de voir à quel point quand même.
Perso j'utilise Oxygen, qui est aussi en Java, et ca va, c'est agréable, mais je sens une certaine lenteur, qui reste acceptable, mais en JavaFX?
Je ne suis pas sur que ce soit une VM, mais un simple interpréteur... (mais j'imagine que c'est une question de sémantique. Bref, osef)Citation:
Envoyé par epsilon68
Difficile de répondre dans l'absolue. Chez moi, une même application utilise entre 10% et 80% du CPU (voir plus, mais c'est quand on affiche une trentaine de flux vidéo en même temps)Citation:
Envoyé par epsilon68
Tout dépend de ce que tu mets dans ton interface
Tu n'as pas dit ce que tu voulais faire avec JavaFx, donc : cela dépendCitation:
Envoyé par epsilon68
je veux faire des accès database, comparer des fichiers, afficher des differences, générer quelques reports, parser des fichiers...
l'interface serait relativement simple: des listes de fichiers, des checkboxes, des textareas pour afficher les différences...
rien de bien compliqué
pour Java:
+ JDBC
+ portable après compilation (ca n'empêche pas de tester sur toutes les plateformes bien entendu)
- jflex/cup pour le parsing, par contre pas de wildcard (vs lemon)
+ generation de report excel facile
+/- lenteur?
pour C++/QtQuick:
- deployment fastidieux
+ lemon (avec wildcard)
- report excel impossible ou très difficile
+ UI attrayant avec QtQuick
+/- CPU?
:salut:
Afin d'être sûr de ne pas faire fausse piste, je vais me permettre de poser quelques questions qui peuvent paraître bêtes mais qui ont, selon moi, leur importance.
Tout d'abord, lorsque tu parles d'utiliser Qt Quick, tu entends bien par là utiliser QML ?
Sauf erreur de ma part, un code QML ne peut pas se lancer seul. J'entends par là qu'il faut obligatoirement l'associer à du C++ (Qt) ou du Python (PyQt) par exemple, à moins de créer un exécutable standalone de qmlscene. (au passage si tu optes pour cette solution ça m'intéresse ;)).
Si tu optes pour du C++/QML tu devras forcément passer par de la compile. Si ce n'est pas toi, alors ça sera les utilisateurs de ton programme.
Si tu optes pour du Python/QML, pas de compilation obligatoire, mais il faudra avoir PyQt (et donc Python) d'installé...
Le choix du SGDB (postgre ou oracle) est-il réellement arrêté ? Car si oui tu devras forcément passer par du Qt pour recréer un nouveau composant QML permettant de manipuler ces bases de données. Malheureusement le module LocalStorage de QML ne gère que des bases Sqlite, et il ne me semble pas avoir vu quelques choses de nouveau dans cette partie pour Qt 5.5.
Concernant la vitesse de traitement, je travaille actuellement sur la création d'un ERP en PyQt / QML. Actuellement je n'ai eu à coder que du QML. Tout est très fluide.
J'ai eu à utiliser un autre ERP écrit en Java et guère plus complexe que le mien ... et bien très sincèrement et même si c'est sûrement très subjectif le mien est plus rapide... ne serait-ce qu'au lancement.
J'ai eu à faire quelques tests de rapidité entre un code 100% QML lancé par un script Python et un code 100% Python : avantage au QML.
Sauf erreur de ma part, Python n'a pas à rougir devant les performances de Java, donc ... :mouarf:
Pour finir, tu parles de faire un code closed source. Je suis loin d'être un spécialiste des licences, mais as-tu vérifié que ceci soit possible avec Qt ?
Avis personnel : moi j'opterai pour Qt Quick + open source ;)
Bonne continuation à toi.
++
J
Oui QtQuick est basé sur QML.
Aussi oui j'utiliserais c++ pour code applicatif.
En outre pas de prob pour sqlite (j'ai une lib pour ca), et j'utiliserais QtSql pour me connecter a Oracle et Postgres.
En ce qui concerne la license, Qt est LPGL donc c'est bon.
Maintenant pour mettre l'appli dans le store, il faudra surement une license, ce qui est embetant quand meme.
Du coup, l'API graphique n'est pas critique, c'est surtout au niveau des fonctionnalités du langage et des libs que tu dois comparer. Et comparer les performances de la gestion des BD (en prenant en compte le temps de dev et de maintenance).Citation:
Envoyé par epsilon68
Vu ce que tu veux faire, QtQuick ou JavaFX, ça sera pareil
Un fichier Excel de base, c'est juste un fichier texte + tabulation (+ modèle de document pour la mise en forme). Rien d'impossible, quelque soit le langageCitation:
Envoyé par epsilon68
Osef de la portabilité du binaire. Cela change quelque chose que ce soit portable avant ou après compilation ?Citation:
Envoyé par epsilon68
A priori (sauf si tu as un volume de données conséquent à traiter, ie plusieurs centaines de Go), tu n'as pas des besoins en performances critiques. Donc a priori, Java ou C++ sera performantCitation:
Envoyé par epsilon68
Du coup, tu ne créés pas réellement un exécutable, tu utilises un exécutable existant (qmlscene). Si tu fais une application 100% QML, tu as juste à ouvrir le fichier qml principal et cela fonctionne (c'est comme cela que Qt Creator lance un qmlproject. Tu peux aussi lancer manuellement le qmlscene sur un QML dans Outils > QtQuick > qmlscene)Citation:
Envoyé par Jiyuu
Si tu as un code métier C++, tu peux créer un plugin, qui sera chargé automatiquement par le qmlscene
Quel store ?Citation:
Envoyé par epsilon68
Si tu parles du iOS store (30% du marché), déjà tu oublies Java.
Pour le store Android, pas de problème pour publier une application QML avec la licence LGPL (à ma connaissance)
J'ai l'impression que tu utilises des critères un peu... "subjectifs" pour faire ton choix.
Si tu connais mieux un langage, utilise le. Si tu n'as aucune idée, fais un petit projet de test avec les 2 langages et compare ce qui te semble critique.
je ne veux pas d'une interface qui donne une impression de lenteur,Citation:
Envoyé par mintho carmo
c'est l'experience que j'avais avec Java sur le Desktop, je demandais si c'était pareil avec JavaFX.
rien d'impossible, mais le temps c'est de l'argent. J'ai toutes les libs Java pour le faire (et ppt et autre), en c++ c'est autre chose.Citation:
Envoyé par mintho carmo
oui ca change quelque choseCitation:
Envoyé par mintho carmo
dans le cas du c++, je dois me refaire toute la chaine de compilation et de compiler les libs que j'utilise en priant qu'il n'y ait pas une erreur de compilation ou de linkage.
pas d'après mon expérience et pas la peine d'aller dans les centaines de Go...Citation:
Envoyé par mintho carmo
J'aimerais avoir un vrai retour d'expérience.
je ferais un vrai exe qui lancera mon Qml et j'aurais du code c++ pour executer le code metier.Citation:
Envoyé par mintho carmo
Je veux faire une appli Desktop.Citation:
Envoyé par mintho carmo
donc j'aimerais deployer sur le macstore et le windows store (pour windows 10)
Je connais très bien le C++ et Java, pas de problème de ce côté làCitation:
Envoyé par mintho carmo
Les critères ne sont pas subjectifs, je voulais un vrai retour d'experience, pourrais tu m'apporter des faits pour justifier ce que tu avances?
Ok... donc dans certaines applications QtQuick, j'ai obtenu 90% d'utilisation du CPU. Et j'ai vu des applications Java être fluide.Citation:
Envoyé par epsilon68
Donc pour moi, vu le type d'application que tu veux faire, tu peux utiliser les 2. Si tu as un problème, c'est pas un problème de langage/lib, c'est un problème de code
ok merci, et les applis java étaient faite en JavaFX? en Swing?
Aucune idée
ok :-/ mais tout ca ne m'aide pas vraiment à choisir.
A priori j'aurais moins de problème avec Java.
C'est ce que je te dis depuis le début.Citation:
Envoyé par epsilon68
Tu n'as pas de contrainte particulière sur le choix du langage, donc utilise celui que tu connais le mieux
Oui, à priori j'aurais moins de problème avec Java.
Pour donner du grain à moudre: j'ai une application JDowloader qui met bien 1 minute à s'ouvrir. La raison que j'ai vu sur Internet; en grande partie à cause du lancement de la VM et aussi des appels réseaux
Ce qui est un problème avec JDowloader, pas de Java. yEd dont je parlais avant met 4 secondes pour démarrer chez moi, chargement des plugins compris. Donc c'est pas le lancement d'une appli Java qui est long, c'est cette appli là en particulierCitation:
Envoyé par foetus
mais c'est quand même un symptôme des applis java, la lenteur se fait ressentir.
Mouais. Bof. Si j'ai des applications Java qui sont lentes et d'autres qui sont correctes en termes de rapidité, je ne vais pas dire que c'est le Java le problème, mais plutôt les devs qui ont écrit ces applis.
(et remarque, je suis un C++ien convaincu, qui déteste le Java. Mais on peut pas reprocher au langage les erreurs des devs)
mais si eclipse a fait SWT en son temps c'est qu'il y avait bien un problème de lenteur.
OxygenXML je l'utilise tout le temps, j'en suis content, il est écrit en Java, et on ressent une certaine lenteur quand même. Je ne pense pas qu'elle soit mal programmée.
tu prenais c# au debut vs VB/MFC/etc, on voyait une sacré différence de rapidité entre les deux
Je trouvais qu'il manquait un epilogue à ce thread, alors voila.
J'ai finalement pris Java puis rapidement Kotlin avec intellij et j'ai fait l'interface en javafx.
J'ai vraiment codé rapidement, et le jdbc est vraiment pratique vu que toutes les dbs le proposent.
Au final, mes apps ne sont pas lentes et peuvent tourner sans exe et sans install.
donc c'etait vraiment tout gagnant.
j'ai recemment commencé une toute petite app sur Qt/quick, pour faire une equivalence d'un autre petit programme ecrit en javafx et Kotlin (avec coroutine).
En Qt, j'ai deux classes Qt juste pour faire l'action en asynchrone, puis j'ai buté sur comment transféré une structure coté QML (finalement je viens de voir qu'on peut utiliser Q_GADGET sur une structure/class). Bon au final, j'ai transmis un QVariant mais je n'ai plus de type (et sonc d'intellisense) coté QML. J'aurais pu utiliser QWidget mais comme QtQuick c'est le futur (c'est vendu comme ca du moins) j'ai voulu faire. Bon ca ne m'a pas deplu, mais je n'etais plus habitué à faire autant d'effort pour juste un traitement asynchrone.
en javafx, j'ai fait mon xml pour la presentation, puis mon controller en kotlin, et une coroutine pour le traitement asynchrone. tres simple et resultat tres propre.
Au final ce que j'en pense, c'est que j'en viens à me demander si je devrais utiliser C++ dans le futur. (Edit: Je connais très bien le C++)
Je ne suis pas sûr, on perd un temps fou dans des details, et aussi une erreur decompil soudain apparait, longure de 3 km. ha oui fallait faire "run qmake" pour regenerer le makefile. (j'ai perdu un certain temps).
J'ai oublié de vous dire que j'ai aussi fait ce programme en cocoa objective C++, et la c'est OK, plus de probleme d'interface vraiment, c'est assez simple, le cote asynchrone avec grand central dispatch, le coté c++ va encore, xcode est mieux que Qt creator (Qt Creator a fait d'enormes progres dans intellisense, c'est remarquable). Franchement cocoa est un des meilleur framework graphique (pour moi peut etre le meilleur)
donc mon avis, c'est de prendre Kotlin, ou bien cocoa si c'est mac only. Si on veut le C++ pour des raisons de memoire (je dis pas les perf car j'ai vu que java n'etait pas lent, bien au contraire, par contre qu'est ce ca consomme de la RAM...) et multiplateforme, alors Qt. Maintenant QtQuick (2 mondes c++ javascript) ou QtWidget, Qt quick est pas mal, et peut aussi etre sur mobile, mais cette separation peut être embetante. Et finalement de nos jours, le garbage collector est vraiment appreciable, surtout avec les lambdas et le multithread où savoir qui est le owner est vraiment délicat.
edit: j'ai fait encore des tests, et je regardais la consommation memoire sur des lists de 5 milliards d'elements (avec un algo d'intersection sur deux lists) et la le java consomme 4,5 GB quand c++ consomme 240 MB
ca fait reflechir... non?
Je n'ai jamais été fan de ce genre de comparaison entre langages. Par ce que généralement, ce n'est pas très pertinent. Chaque langage a ses idiomes, ses pratiques, se pièges, une courbe d'apprentissage spécifique. Je suis sur qu'un dev Java expérimenté pourra te corriger ton code pour que tes listes ne prennent pas plusieurs Go. Et pour un dev C++, utiliser des list fait généralement dresser les cheveux sur la tête.
Le C++ est connu pour avoir une courbe d'apprentissage plus dur que les autres langages. S'amuser à refaire une appli avec différents langages que tu ne maîtrises pas, je ne suis pas surpris que tu as eu des difficultés avec le C++. Et c'est effectivement un bon conseil pour les débutants : si vous ne voulez/pouvez pas prendre le temps d'étudier correctement le C++ avant de vous lancer la création d'une appli, il ne vaut pas choisir le C++.
Je suis un DEV java expérimenté, et là le but de l'exercice etait de faire un algo sur 2 listes d'entier. Et pourquoi ca ferait dresser les cheveux sur la tête d'utiliser des listes d'entier ? explique. Dans ce cas précis j'ai poussé le vice à plusieursCitation:
Envoyé par mintho carmo
milliardsmillions d'elements, ce qui devrait rarement arriver, mais c'est pour voir comment le temps d'execution et l'occupation memoire evoluent.
Je n'ai aucun problème en C++ (deja realisé un soft 3D opengl). Le but de l'exercice etait de faire une action asynchrone dans les 3 implementations (Kotlin/JavaFx, Cocoa/Objective C++ et Qt). J'ai donné mon retour d'experience sur les 3 implementations et j'ai voulu aussi donner un autre point de vue, celui de l'occupation mémoire. C'est pas nouveau, mais j'ai été particulierement choqué de la différence, et j'ai trouvé cela utile de le partager.Citation:
Envoyé par mintho carmo
Honnetement, plutot que de sortir des reflexions pareilles, tu devrais peut etre partager tes propres experiences.
Parce que si tu parles de std::list, c'est pas du tout cache-friendly.Citation:
Envoyé par epsilon68
C'est ce que j'ai fait : de ma propre expérience, ce genre de comparaison n'est pas pertinent.Citation:
Envoyé par epsilon68
en c++ j'ai pris des std::vector et en Kotlin des ArrayList...Citation:
Envoyé par mintho carmo
c'est ce qu'on appelle des listes d'entiers, je n'avais pas précisé, et je n'avais pas non plus vraiment parlé de performance, j'avais plutot insisté sur la consommation mémoire. Et puisque tu en parles, Java etait plus rapide sur l'algorithme d'intersection mais hyper lent sur la génération des nombres aléatoires.
mais je dirais que la perf etait un detail, je n'en ai meme pas parlé et rien précisé. Et je ne rendrais pas les sources public.
non tu as rien fait justement, tu as lu de travers, tu as supposé des choses fausses et rien n'était constructif. D'ailleurs je me disais, en lisant ton commentaire, si ca valait vraiment le coup de partager son expérience pour qu'elle soit reçu de cette facon. (les devs confirmés ne feraient jamais ca, pourquoi tu apprends pas le c++ avant de programmer? c'est nul les listes d'int, ca sert a rien de comparer les langages)Citation:
Envoyé par mintho carmo
je t'encourage à partager ton experience, et à subir ce même genre de commentaire dé-constructif.
Je demande le vote du public, mais je ne connais pas beaucoup de devs C++ qui parlerait de "liste" pour parlait de std::vector.Citation:
Envoyé par epsilon68
Et je parlais aussi de consomation mémoire, qui est très différente entre std::vector et std::list.
Partager des "analyses" personnelles de comparaison de quelques tests, je l'ai déjà fait. Sur des questions techniques, en donnant toutes les informations qui permettent de comprendre correctement ce qui est fait, pourquoi et ce que j'en conclue. Pour avoir des analyses différentes, avoir une vision plus large des problématiques.Citation:
Envoyé par epsilon68
Mais le type de comparaison que tu fais dépend beaucoup des compétences du dev, de son expérience sur les langages et les frameworks, le type d'application, etc. C'est totalement subjectif et à part dire "moi je préfère ça", c'est impossible à transposer à une autre personne. Dit autrement, si quelqu'un se pose la question du choix d'un langage, il tombera sur plusieurs discussions comme celle-ci, où la conclusion est "moi je préfère ça".
Que ça te plaise ou non, il faut se poser la question de la pertinence d'une comparaison.
tu te rends compte que quand on parle au niveau conceptuel, on dit juste une liste?Citation:
Envoyé par mintho carmo
une List en Java est une abstraction, ArrayList est une implementation.
faut surement parler differemment aux developpeurs C++?
Ou alors tu fais partie de ces developpeurs à qui faut tout expliquer dans le details?
je n'ai pas mis de code, je voulais vraiment donner une opinion, un retour d'experience, pas rentrer dans les details d'implementation.
Java prendra toujours (beaucoup) plus de memoire que c++, c'est un fait, et il faut clairement le savoir quand on prend une decision. J'ai meme été étonné d'une telle différence c'est pour cette raison que je l'ai souligné. Essaie sur un example mais avec un grand nombre et regarde puis dis nous.
oui c'est vrai que c'est une partie subjective, ce que je trouve élégant dans une coroutine est personnel, j'imagine que d'autre vont preferer l'objective C++ avec grand central dispatch, je ne sais pas, et d'autre Qt et Qt concurrent. on peut tout imaginer et tout discrediter.Citation:
Envoyé par mintho carmo
et puis un choix depend des contraintes du depart, mais faut-il vraiment faire un preambule de 50 pages avant de donner un retour d'experience? et de toute facon, y aura tout le temps quelqu'un pour dire que c'est nul, la preuve.
comme retour, j'aurais plutot preferé : "moi j'ai observé que etc etc" ou alors "Comment as tu fait la tache asynchrone en Qt car j'ai une bonne facon de faire qui est celle ci et que je trouve elegante" etc.
J'imagine que c'est chacun son truc. Cette discussion est stérile, je ne la continuerais pas, et comme tu as dis "je demande l'avis du public".
Moi, perso, j'ai aimé le retour d'expérience que j'ai trouvé intéressant. Je comprends qu'il y ait des blocages sur l'utilisation de Qt avec le QML, car c'est une chose qui s'apprend, plus ou moins facilement. Dans d'autres langages, il n'a pas ce genre de "communication" entre deux langages/paradigmes. Mais pour autant, le QML n'est pas mauvais.
Pour la consommation mémoire en JAVA, j'avais déjà rencontré ce problème, mais n'étant pas expert en JAVA, je ne sais pas régler une telle chose. Juste, ça m’horripile une telle chose, venant d'un monde C++.
Par contre, pour l'intersection de cinq milliards d'éléments, la consommation mémoire énoncée pour le C++ me parait basse, non ? (sauf si les 5 milliards d'éléments ne sont pas en mémoire, évidemment.)
Merci pour cette note positive! QML est plutot cool mais il faut faire plus de chose que en javafx ou cocoa. De toute facon il n'existe pas d'alternative pour du cross plateforme en C++ que Qt.Citation:
Envoyé par LittleWhite
tu as raison c'est bizarre, il faut que je verifie quel nombre exactement j'ai utilisé mais je suis sûr du ratio entre java et C++. je verifie des que possible et j'editerai mon message.Citation:
Envoyé par LittleWhite
Edit: oui c'est 50 millions d'elements, effectivement tu avais raison :-)