Philippe F a écrit 2204 commentaires

C'est intéressant.

(Note: je ne fais plus que du PyQt depuis longtemps, j'ai perdu de vue Qt/C++ depuis la version 3).

De fait, utiliser Qt fonctionne bien avec une cohérence globale au niveau de ses types, de ses conteneurs et autres. Il arrive bien à échanger des données avec des conteneurs et types externes mais c'est plus une notion d'import/export que d'interopérabilité. Ca ne m'étonne pas que le mélange profond des deux au sein d'un même programme se passe pas bien.

Donc ça force un style particuliers de programmation, avec des QThread, des QString, des QObject et des QList. Quand j'ai commencé, j'ai trouvé que ce style "forcé" était de bonne qualité et donc ça m'a plutôt plu. Mais je conçois que ça puisse poser des problèmes.

Lorsque Qt est arrivé en 1994, c'était vraiment une révolution. On était même pas sur de trouver une STL fonctionnelle sur toutes les plate-formes, et à côté, on avait Qt qui fournissait bien plus que la STL, avec une meilleure documentation et une interface plus abordable.

Depuis, la STL a rattrapé une partie de son retard et devient relativement utilisable (bien qu'un peu lourdingue à mon goût), surtout avec du boost.

Donc Qt peut être vu comme une solution non standard. Je râlais de la même façon quand je faisais des MFC et que je n'arrivais pas à faire marcher mes std::string et que Microsoft m'obligeais à utiliser des CString (les string en MFC). J'aurai jamais pensé que l'argument se retournerai contre mon toolkit adoré un jour.

std::cout << monQString;

Je pense qu'il y a de bonnes raisons à ça. Au hasard, je dirai que comme la STL ne spécifie pas réellement d'encoding par défaut, suivant les options de compilations que tu passes à ton programme, il faut que les chaînes soit encodées en UTF8, UTF16 ou UTF32, voire même latin1.

Donc Qt t'oblige à faire le choix toi-même, en convertissant soit en UTF8 avec tu toUtf8(), soit en en encoding "locale" avec toLocal8bit().

Et si tu veux afficher cette même chaîne sur un terminal, l'encoding final à choisir est assez complexe : sous Windows, il faut probablement la convertir un cp1252 ou en UTF8 suivant la version de Windows et de la console, sous Linux UTF8 a l'air de s'en sortir pas trop mal. Je doute honnètement que cout gère ce genre de subtilité, donc au final, ton code sera probablement pas portable.

Demande à Victor Stinner le cauchemar que c'est de faire marcher l'unicode correctement sous Python.

En tant que développeur, je serai curieux de connaitre les exemples concrets sur la non-intégration STL, l'utilisation de pointeurs ou la gestion des threads. Il me semblait que beaucoup de chemin avait été fait dans ce sens.

Pour une appli KDE ou Gnome, ca peut poser des problèmes car les applications dépendent d'autres services lancées par le desktop (dbus, …), qui sont accédés via un mécanisme d'IPC. Donc ça ne sera pas embarqué dans l'archive.

La bonne manière de faire est probablement de démarrer carrément KDE avec CARE, mais bonjour la taille de l'archive ! Et encore, est-ce que CARE gère les forks et continue à suivre les deux processus ?

Moi j'aime bien les projets qui numérotent leurs versions avec le hash mercurial, c'est toujours beaucoup plus parlant.

Genre:

Quidam : t'as essayé la dernière e9a8d5e17e1c031fc7e47f308cdb3515282009b7 de Trucmuche ? Trop de la balle, sauf le bug quand tu schtroumpfes un site écrit en shilpse !

Deuxième quidam: T'es trop à la rue toi ! Ca fait un bail que le le bug est corrigé, au moins depuis la e8149dafa166e11a71a69b016427fc102c1e8a70

En même temps, YouTube "squatte" un service qu'il ne paye pas, à savoir de la bande passante sur des grosses interconnexion. On est arrivé à la période où cette utilisation démesurée d'une ressource commence à avoir un coût non négligeable qui ne peut plus être absorbée dans le cadre d'un service "général".

Ça ne me parait pas choquant qu'un acteur comme YouTube se retrouve à devoir payer une partie des coûts qu'il engendre pour son utilisation démesurée d'une ressource.

A côté, je n'ai rien vu qui remette en question le fait que les autres contenus serait accessibles à une vitesse raisonnable.

Ça serait juste de la pure malhonnêteté de dire que personne n'est censuré.

Au contraire, pour l'instant, je n'ai rien vu dans ce sens. Les gens n'arrêtent pas de faire des amalgames entre augmenter le débit de service précis qui payent pour cela, et la censure.

Si tu veux diffuser un film imaginons contre la tuerie des baleines traduit en 45 langues dans le monde entier sur Internet, tu sera dans la situation suivante:

1. Tu peux mettre ton film sur YouTube et profiter du débit fantastique négocié par YouTube.

2. YouTube n'aime pas ton film, tu peux déjà aller voir les concurrents de YouTube (DailyMotion, …)

3. Pas de bol, tous les concurrents de YouTube veulent censurer ton film. Il te faut donc le diffuser par tes propres moyens. Tu te prends une dedibox avec 1Gbit et éventuellement des services équivalent dans d'autres pays. Pour un prix raisonnable par mois, tu as une bonne bande passante raisonnable et tu n'es toujours pas censuré.

4. Pas de bol, même OVH et Amazon ne veulent pas héberger ton film sur les tueries des baleines. Dans ce cas, tu peux travailler avec des associations type GreenPeace ou EFF pour trouver des solutions. Tu peux aussi mettre ton film sur Tor ou en P2P ou chez MegaUpload.

Bref, il reste encore pas mal de solutions.

Pour l'instant, c'est un peu comme si tu appelais à la censure du forum de Davos parce que tu dois payer un billet d'avion pour y aller.

Après si tu veux monter un service commercial et payant, on parle d'autre chose. Mais on se retrouve avec la même question. Si tu abuse d'une ressource, il est normal qu'il y aie une contrepartie payante.

Un truc sympa avec Qt qu'on mentionne pas souvent, c'est que la gestion de la mémoire est bien foutue. Il y a un garbage collector basé sur du comptage de référence qui est bien en phase avec le besoin: comprendre, ça marche très bien et très discrètement quand on a besoin, mais c'est pas un Garbage Collector générique de la mort qui tue.

A l'époque surtout, c'était une vraie révolution de ne plus se torturer les méninges sur qui doit détruire l'objet string dont tu retournes le pointeur dans ta fonction. En Qt, tu retournes une string et elle sera détruite quand tu n'en aura plus besoin, même si tu sais pas quand ça arrive.

Qt a carrément modifié en force le C++ de manière à faire rentrer des objets ronds dans des trous carrés, et que le résultat n'est pas vraiment du C++ :-)

C'est un peu exagéré quand même. Je dirai ça plutôt de GObject. Pour Qt, c'est juste des objets ronds dans des trous ovals, c'est beaucoup plus raisonnable…

C'est surtout que UTF8 et ses copains sont aussi des normes ISO, donc on peut y faire référence dans une norme ISO. Tandis que cp1252 n'est pas une norme ISO.

Ah l'ISO… De ce que je connais, il n'y a que deux approches de la normalisation ISO:

1. la "branlette intellectuelle": des mecs pointus te pondent un standard en réfléchissant aux besoins de dans 10 ans. Ils font un truc, très complet, très théorique et très difficile à mettre en oeuvre. Au final, quand le besoin de dans 10 ans arrive, tout le monde a utilisé une méthode 10 fois plus simple et moins compatible pour faire la même chose.

2. la normalisation a posteriori: le truc qui a été inventé il y a 20 ans, qui est un standard de fait depuis 10 ans finit dans l'ISO pour y vivre paisiblement … et y mourir.

Dans quelques rares cas, l'ISO pond un truc utilisable dès aujourd'hui pour les besoins d'aujourd'hui.

Quand tu es programmeur dans le monde réel, l'ISO te semble bien loin.

c'est aussi du boulot de maintenir une telle bibliothèque

C'est quoi cet argument ? Parce que pondre un standard, c'est pas du boulot ? Le but d'une bibliothèque, c'est bien de faire gagner du temps au développeur en prenant en charge une tâche difficile. Si ta lib ne fournit que des services faciles à implémenter directement par le développeur, elle ne sert à rien, il la fera lui-même (ce qui est le cas pour beaucoup de bibliothèques gérant des strings).

En plus pour le coup, ton argument tombe à plat: ajouter l'encodage cp1252, c'est un truc que tu fais une fois dans la vie de la bibliothèque, ça ne bouge plus jamais. Les string C++ ayant déjà de quoi gérer les conversions vers l'UTF8, UTF16, UTF32, UCS2 et UCS4, c'est pas dur de rajouter d'autres encodings.

Pour voir ce que ça donne quand tu fais le travail jusqu'au bout: http://docs.python.org/3/library/codecs.html#standard-encodings

J'avais discuté du sujet avec plusieurs personnes pointues sur le sujet (notamment le mainteneur du binding gtkmm (gtk pour C++).

Faire des bindings pour une lib en C est très facile d'approche. Il n'y a peu de difficultés techniques (d'apparence en tout cas) et c'est un très bon projet libre pour se mettre dans le bain. C'est pour ça qu'on en trouve autant.

Faire des bindings pour une lib en C++ est beaucoup plus difficile à réaliser d'entrée de jeu. On se trouve immédiatement confronté à de grosses difficulté. En effet, tous les bindings vers d'autres langages fonctionnent à partir du C (en tout cas, ceux que j'ai vu). Il faut donc faire une grosse couche de C, et ensuite, dans le langage cible, il faut quand même reconstituer l'interface objet pour que ca ressemble à l'original. Assez fastidieux. Il me semble aussi que le passage de référence est plus complexe en C++ qu'en C. Il faut aussi surcharger d'emblées toutes les méthodes virtuelles pour les fournir dans le langage cible, etc etc.

Le C part donc avec un gros avantage au départ … mais seulement au départ. En effet, l'approche des bindings en C suppose une très grosse part de travail manuel pour analyer les structures fournies par Gtk et en faires des objets cohérents dans le langage cible. C'est le problème inhérent de Gtk: la couche objet n'est pas "native" en C, et doit donc être reconstruite à la main.

C'est pour ça que les bindings en C ont très souvent (ou en tout cas avaient très souvent) une voire plusieurs release de retard: il y a un gros effort qui est fourni à un moment donné pour avoir une version stable, mais intégrer les nouvelles versions quand elles sortent représente un travail massif qui dépasse sur la durée la capacité des contributeurs les plus motivés (c'était comme ça il y a 10 ans en tout cas).

Le C++, au contraire se prête assez bien à une génération automatique. Parser un header C++ apporte presque toutes les informations nécessaire à la création du binding. Il faut quand même complémenter quelques informations (la gestion de propriété des pointeurs par exemple). Mais sur la durée, ca tient mieux la route: une fois la grosse machinerie initiale mise en place, mettre à jour pour des nouvelles classes ou une nouvelle version demande un travail manuel beaucoup plus limité.

Voici ce qu'en disent les pages sur les deux outils majeurs pour cette tâche:

• SIP

  SIP comprises a code generator and a Python module. The code generator processes a set of specification files and generates C or C++ code which is then compiled to create the bindings extension module. The SIP Python module provides support functions to the automatically generated code.

  The specification files contains a description of the interface of the C or C++ library, i.e. the classes, methods, functions and variables. The format of a specification file is almost identical to a C or C++ header file, so much so that the easiest way of creating a specification file is to edit the corresponding header file.

• Smoke

  To generate SMOKE libs for your own libs and APIs, a new tool has been written, called 'smokegen' […]. smokegen itself only does the parsing of C++ header files […]

Côté KDE, l'infatigable Richard Dale a travaillé avec David Faure sur Smoke pour faire des bindings pour Perl, Php, Ruby et C# si je me souviens bien. Aucun n'a pris non pas parce qu'ils sont mauvais, mais parce qu'il n'y a peu d'intérêt (voire aucun) à avoir Qt pour ces langages. Les programmeurs Qt se satisfont globalement très bien de C++, ceux qui trouvent ça trop lourd se satisfont de Python ou partent rapidement vers Gtk et WxWidget.

Un autre aspect est que pour une lib comme Gtk, le C reste assez lourd à manipuler. Des langages comme Python, Vala, C# ou autres apportent un réel plus en terme de simplicité du code à manipuler et de programmation objet. Qt ne souffre pas du même défaut, les concepts sont très bien exprimés en C++ (voire représentent une simplificaiton du C++, cf mon post plus bas) et la motivation pour écrire dans un langage annexe est beaucoup moins forte.

Pour terminer sur les bindings C difficiles à générer, la situation n'a pas échappé aux mainteneurs côté Gtk. Lassés de faire un gros travail à la main à chaque release, ils ont planché sur une amélioration de GObject, pour fournir de base suffisamment d'information pour automatiser la génération: c'est l'introspection GObject . Si j'en crois la page de bindings de Gtk, le travail a l'air d'avoir payé puisque les bindings vers les langages majeurs sont bien à jour.

Allez, pour finir, un petit troll: en dehors des développeurs de Mandrake, quelqu'un connait des malades développeurs que utilisent PerlGtk ?

C'est mieux que la dernière fois que j'avais regardé, mais c'est pas encore ça. Je note d'ailleurs que les fonctions qui traitent une string comme plus qu'un tableau de caractères ont été rajoutés en C++11 (conversion vers ou depuis des entiers et float).

Si tu veux une string qui contient de l'utf8 mais que tu dois l'afficher sur un terminal en police cp1252 (cas typique d'un fichier que tu lis sur ton disque dur et que tu affiches dans un terminal Windows), le standard ne fournit absolument rien. Pourtant, manipuler des strings unicode dans plusieurs encodages, c'est un besoin impératif dès que tu gères des strings en autre chose que l'ascii.

Tu vas me dire de prendre une string du type par exemple std::u16string mais ça ne résoud rien. u16string, c'est juste une string stockant des u16char, mais tu ne sais pas si à l'intérieur, tu as de l'UCS2 ou de l'UTF16.

Et upper(), lower(), contrairement à ce que tu sembles croire, ce ne sont pas des fonctions faciles.

Au contraire, je sais que ce sont des fonctions difficiles, c'est pour ça que je veux qu'elles soient fournies par la plate-forme.

Mais bon, c'est vrai que ça évolue, je vois que le standard fourni maintenant de quoi convertir entre UTF8, UTF16, UCS2, UCS4. Rien pour cp1252 en natif cependant, ils ont jamais du ouvrir un terminal sur un Windows XP français.

Dommage, Qt le fait depuis 1998. Peut-être en C++24, je pourrais l'avoir.

Mais bon, tout ça n'aura pas été inutile, j'ai découvert l'opérateur ""(). Je suis sur qu'en plus de me faire loucher, il doit pouvoir faire des tas de trucs désagréables dans un programme.

Sinon, si tu veux voir ce qu'est une string qui fonctionne pour des applications et pas juste pour des mathématiciens, tu peux jeter un coup d'oeil à :

• Qt: Qtring
• Python: string et string builtin type

c'est juste suffisamment sophistiqué pour n'être en standard ni en C++ 

En même temps, le standard met pas la barre très haut en terme de trucs pratiques. Quand tu vois qu'une vraie string en C++ ou en C, ça n'existe pas…

Une vraie string, c'est pas un tableau de caractère 8bit, c'est un ensemble de codepoint, unicode ou autres (latin1, ascii, cp1252), avec un encoding précis, et des méthodes absolument exotiques du genre: upper(), lower(), contains(), strip().

Par contre, les 14 types de containers suivant que tu gères un ensemble ordonné ou non, itérable ou pas, dans un sens ou dans les deux, ça c'est sur que c'est hyper utile en pratique !

mais C++ est un language qui reste extremement complexe.

Là-dessus, je suis hyper d'accord. Un des atout majeurs de Qt à mon avis est qu'il permet de se restreindre à un très petit sous-ensemble de C++, et de pouvoir quand même faire des trucs très bien. Et le modèle Qt participe beaucoup à cette simplification [1]

J'avoue que bien que j'ai fait du C++/Qt pendant des années, j'ai jamais vraiment compris les template en C++, et que les itérateurs façon std++ sont une acquisition récente. Certains se désoleraient de ma fausse connaissance du C++; je me réjouis pour ma part d'avoir écrit de code lisible et performant en échappant à cette ignominie. Et je ne ressens nul besoin de savoir faire du template meta-programming, pas plus que de savoir dans quels cas je peux lever une exception dans un constructeur appelé par un autre thread et savoir si mon objet sera détruit correctement (objet avec un héritage multiple et destructeur virtuel sur plusieurs étages de classes évidemment).

De mon expérience, le combo C + GObject + Glib + GTK+ n'est pas plus difficile à appréhender ni à utiliser que C++ + Qt

C'est pas réellement plus difficile à appréhender. C'est juste plus pénible, plus sujets à des erreurs, moins lisible.

Petite question au passage, tu trouves pas que #include est surfait et que pour tous les include système, il vaudrait mieux faire des copier coller du code que tu rajoutes pour vraiment savoir comment il fonctionne ? Parce que c'est important de savoir comment tout fonctionne, non ?

[1] C'est aussi d'ailleurs ce qui heurte les puristes: comment, vous utilisez pas la fonctionnalité machin-truc-chose qu'on a introduit la semaine dernière dans le standard C++ qui vous fait ça en une ligne ?

Ben non, Qt fournit du code maison qui fait ça depuis maintenant 20 ans, sur des compilateurs qui supportaient à peine le C++ à l'époque. Et ça marche très bien, c'est lisible et performant. Mais pas de problème, dès que Visual Studio 2024 sort et que j'ai compris comment votre truc marche, je l'utilise.

Ça revient peu ou prou au même, non ? Quelle est la différence entre ajouter un concept objet au C via du C et ajouter des trucs (notamment les signaux) au C++ via un compilateur spécifique ? (AMHA la seconde solution est bien plus intrusive)

Nos points de vues diffèrent. Côté intrusion, Qt me demande une ligne dans mon Makefile, et deux lignes dans mon fichier .h et dans mon fichier .cpp (et encore, c'est que quand je veux déclarer un nouveau signal ou un nouveau slot).

Gtk, et plus précisément GObject demande à recréer à la main tout un formalisme pseudo-objet avec des kilomètres de code pour cela. L'intrusion pour moi se situe au niveau du nombre de lignes de codes "boilerplate" que m'impose la fonctionnalité. Gtk est clairement perdant sur ce champ-là.

Ca diminue la lisibilité du fichier source et c'est très mal de mon point de vue (certaines études montrent que le nombre de bugs écrits par un programmeur est à peu près proportionnel au nombre de lignes qu'il écrit. Deux fois plus de lignes, deux fois plus de bug).

J'avais pas Internet au moment où j'ai fait ce truc, mais j'avais quand même la page de man de git et le tutorial de git… qui ne m'ont pas du tout éclairé.

Au final, je sais comment:
- committer l'inverse d'un commit précédent: ok mais je m'en fous
- supprimer des fichiers de staging que j'aurai ajouté: ok mais je m'en fous, mon fichier n'est pas encore ajouté
- supprimer tous mes changements locaux: on s'en rapproche mais en fait, tous mes changements m'intéressent sauf un sur un fichier que je veux annuler. En fait, c'est plutôt la moitié des changements que je veux annuler (le truc qui prend 10 secondes avec TortoiseHG où tu peux sélectionner dans un fichier ce que tu veux, ou 30 secondes avec TortoiseHG diff + WinMerge).

Toutes les explications sur la comment reset contiennent de très gros warning de attention, vous pouvez tout niquer, vous pouvez tout perdre, faites gaffe. Comme j'y comprends rien, c'est pas encourageant.

Apparemment, pour faire ce que je veux, c'est git checkout avec je sais plus quelle option.

Et donc:
- je suis passé par trois commandes git différentes sans trouver la bonne
- certaines de ces commandes ont 3 cas d'utilisation distincts mais communs (git-reset ).
- c'est blindé de warning "attention danger faite gaffe vous allez tout nicker"

Je sais pas comment on peut être sain d'esprit et prétendre que git est simple à utiliser.

J'utilise Vim tous les jours et je programme en C mais jamais je ne prétendrai que ces deux outils sont simples à utiliser. C'est complexe, c'est long, ça fait mal mais on arrive à en tirer quelque chose. Git, c'est pareil, sauf pour le dernier point.

Ca m'a rappelé l'époque où je lisais les man de sed pour l'utiliser autrement que pour faire des remplacement de lignes…

Bon, nos expériences sont différentes.

D'une part, j'utilise mercurial et subversion depuis des années dans avoir jamais eu besoin de comprendre comment ils fonctionnent en interne.

D'autre part, je viens de perder 2h de ma vie à vouloir faire l'équivalent de la commande "svn revert" sous git pour contribuer à un projet Open Source. Sous mercurial, c'est "hg revert". Au final, n'ayant toujours rien compris aux histoires de tambouille, interne, j'ai installé un client git graphique propriétaire (SmartGit) et j'ai finalement réussi à accomplir le miracle.

Git a gagné la guerre des SCM distribués, mais c'est pas pour le meilleur des mondes. "Worse is better", ca rappelle quelque chose aux vieux barbus ?

J'ai cru que cette nouvelle annoncait le support tant attendu de X-Window pour le vénérable éditeur Ed (logiciel) . Après Vi et Emacs, pourquoi Ed n'aurait-il pas droit à une interface graphique digne de ce nom ?

Je suis déçu…

J'aime bien la réflexion derrière asm.js et derrière dart en général. D'ailleurs, je m'interroge sur le fait que le choix du sous-ensemble de javascript utilisé par asm.js doit être tout aussi facile à optimiser pour SpiderMonkey que pour V8, non ?

Autre question si qq'un a la réponse : pourquoi un outil comme dart2js ne génère-t-il pas de l'asm.js ? Ca peut être une façon détournée de faire un gain en performance sur Firefox.

Par exemple, si l'on cultive des plantes sélectionnées qui ont un rendement deux fois supérieur, on peut nourrir deux fois plus de personnes avec les mêmes ressources naturelles. 

Si tu penses que ça n'est pas naturel ou que c'est contraire aux lois de la nature, tu est sur une position religieuse ou philosophique.

Ou sur une position scientifique tout simplement: rien ne se perd, rien ne se crée.

Ce qui est contraire au lois de la nature, c'est de penser qu'on peut faire plus avec la même quantité de départ.

Si un plant sélectionné de légume est deux fois plus gros qu'un autre, il a pompé deux fois plus de ressources pour se développer: eau, nutriments, etc. La seule ressource infinie qu'il a utilisé est la lumière du soleil, le reste ce sont des ressources naturelles finies qui ont été consommées par la plante.

Certes, une partie de ces nutriments peut-être apportée par des engrais mais pas tous. L'autre partie a été pompée dans le sol (eau, …) et peut conduire si on l'utilise intensément (ce qu'on fait depuis une cinquantaine d'année maintenant) à un appauvrisement du sol. Il ne devient plus capable de "nourrir" correctement les légumes qu'il produit, et ceux-ci, par un effet pervers demandent encore plus d'apports externes pour se développer normalement.

Tu as donc l'impression de faire un gain de productivité et d'avoir augmenté ton rendement mais en fait, tu condamnes ton milieu de production à long terme.

Autre possibilité, ton légume est plus gros, mais en fait, il est gonflé à l'eau, et contient la même quantité, voire moins de nutriments qu'un légume plus petit. L'illusion d'optique fonctionne, sauf que le légume ne rassasie plus et tu es obligé d'en manger plus pour arriver à te nourrir [1].

J'ai pas d'études scientifiques sous la main, mais il a été clairement analysé que les légumes produits de façon non intense (typiquement, en bio) contiennent plus de matière sèche qu'un légume produit de façon intense (typiquement, aux étals de grandes surfaces). Au final, tu as utilisé plus de nutriments et d'intrants chimiques, alors que la personne mangerai un légume petit et boirait un vers d'eau et aurait le même résultat.

Donc tu n'a pas résolu ton problème.

Tu créées même des effets pervers, puisque le cerveau emmagasine une fausse information, qu'il faut manger plus pour arriver à la sensation de satiété, alors que le problème vient de la qualité. En plus de la taille du légume, les industriels vont bien sur jouer sur tous les paramètres possibles pour créer une dépendance psychologique accrue à ce "faux" légume : couleur standardisée, un peu plus de sucre pour stimuler les zones de plaisir, un peu de brillant pour qu'il ressemble à une photo de papier glacé, suppression des légumes avec des "défauts" pour que la personne oublie même que cela existe. Tous ces facteurs font que au final, tu crois faire un gain de productivité alors que tu ajoutes un maillon à la chaîne de la surconsommation, qui crée un appauvrissement global de notre monde.

Donc je m'élève en faux contre cette affirmation, de la possibilité de la croissance infinie: « on peut nourrir deux fois plus de personnes avec les mêmes ressources naturelles ».

[1]: je n'ai que mon expérience personnelle et mon entourage pour vous dire que manger un légume bio rassasie mieux. Le goût est plus intense, et au final on en consomme moins. Pour avoir la même sensation de satiété avec des légumes non bio, j'ai besoin d'en manger plus…

Tiens, petite anecdote à propos de cette approche de lien symbolique. Au temps de KDE 2, je me souviens qu'ils avaient travaillé sur l'optimisation du temps de lancement de KDE. Ils avaient constaté que certains services KDE qui sont lancés par Shell étaient lancés avec /bin/sh mais en fait étaient lancés par /bin/bash à cause des liens symboliques, et bash prenaient énormément de temps à démarrer, parce que le shell est bien plus compliqué que sh.

Au final, trouver le vrai sh ou remplacer les scripts triviaux par un programme en C plus simple avait fait un gain significatif sur le temps de lancement.

Il y a le vieux trucs de rappeler régulièrement dans l'application que c'est une version on enregistrée et qu'il faut payer pour l'utiliser.

Façon WinRar, avec le bouton de la souris positionné par défaut sur "j'achète" et un déplacement aléatoire de ce bouton pour que tu ne puisses pas avoir un geste mécanique "je clique sur le bouton du haut".

Ou façon SublimeText où quand tu sauves ton programme, régulièrement (2-3 fois par jours), il te rappelle de t'enregistrer.

Après, je sais pas si ça marche. Vu l'acharnement de WinRar, j'aurai tendance à dire que l'auteur était pas tout à fait satisfait du rapport "nombre de personnes qui achètent" / "nombre de personnes qui l'utilisent".

Et tu en vies ? Zenitram arrive apparamment à vivre de son logiciel.

Et Bruno Coudoin ? Et toi ?

Si je résume: quand une personne qui fait passer un test de programmation à un candidat et connait bien son métier par ailleurs, ça laisse une bonne impression au candidat. Quand elle n'y connait rien, ça laisse une mauvaise impression. Finalement, cette histoire de test, c'est un peu comme les bons chasseurs…

Perso, j'ai fait passer des tests pour recruter des stagiaires. C'est normalement entre 15 et 30 minutes et ça suffit largement pour se faire une idée des qualités de développeurs du candidat. Par contre, 3h, c'est un truc de malade! Je ferai un truc comme ça en phase 2 ou 3 du recrutement à la rigueur.

Sur un test de 15 minutes on voit immédiatement quelques paramètres objectifs:

• est-ce que le candidat pose des questions lorsqu'il manque des informations pour réaliser sa tâche ?
• est-ce qu'il a suffisamment écouté pour réaliser l'exercice correctement (dans 90% des cas, non).
• est-ce qu'il aborde le problème de façon structurée ?
• est-ce qu'il comprend ce qu'il écrit ?
• est-ce qu'il arrive à écrire un programme qui marche ?
• est-ce qu'il est réellement familier avec le langage qu'il prétend maitriser ?

Ensuite, on discute de son programme, on identifie ensemble des points faibles ou forts, on réfléchit à la gestion mémoire (c'est à dire, est-ce qu'il connait les concepts en dessous des outils qu'il utilise ?), à la souplesse du programme, etc.

C'est un exercice participatif, constructif et très révélateur du niveau général du candidat.

J'avais regardé et j'avais trouvé le langage plutôt plaisant. Il permet de faire ce que je fais d'habitude avec une certaine simplicité, souplesse et robustesse.

La doc est un peu minimaliste mais on s'en sort.

Par contre, je voulais en profiter pour faire un projet loisir avec une interface graphique et là, c'est la misère. C'est plus orienté système.

Et vu la structure du langage, je vois pas bien comment ils vont me faire mon binding préféré, le goqt …

J'ai longtemps pensé que l'approche à la WxWidget était la bonne, car le portage vers une nouvelle plate-forme voulait uniquement dire de faire rentrer les contrôles existants dans l'api de WxWidget. Toute la partie look devenait natif et suivait la plate-forme (ce qui faisait taire les râleurs).

A l'inverse Qt, pour un nouveau portage, doit redévelopper un système d'affichage bas-niveau. Et quand il y a des nouveaux moteurs de look (Win98 -> XP -> Vista -> Seven), il faut redévelopper le moteur de thème pour tirer partie des derniers moteurs. C'est un problème en particuliers quand une plate-forme non majeur sort un nouveau moteur, il se peut que les développeurs de Qt ne soient pas rapides à l'intégrer et on voit alors des trolls surgir sur Linuxfr.

J'ai cependant complètement changé d'avis avec le temps et à l'utilisation de Qt. Au fur à mesure que Qt a pris en maturité, les contrôles/widgets sont devenus de plus en plus élaborés, bien plus que ceux qu'on trouve en natif sur la plate-forme, battant en brèche un des avantages de WxWidget.

De plus en terme de debug, les widgets de Qt sont débuggés une fois pour toute, le code étant commun à plusieurs plate-formes, alors qu'il est régulier que Wx se traîne des bugs spécifiques à des plate-formes. Et je ne peux pas les blâmer pour ça, qui peut garantir que par exemple les ascenseurs Windows, MacOs et Gtk soient complètement "unifiables" en terme d’événements envoyés à la pile graphique.

Au final, la stratégie de Qt paye sur le long terme. Au fur à mesure que le nombre de plate-forme augmente, et le nombre de widget aussi, l'effort de développement côté Qt reste relativement linéaire avec une pente assez douce, car dès que le moteur graphique est porté, tous les widgets suivent instantanément. De même, pour un nouveau look'n feel, Qt a maintenant un moteur de style suffisamment costaud pour absorber beaucoup des dernières nouveautés.

Pour Wx, chaque nouvelle plate-forme multiple de façon exponentiel le travail de maintenance et d'évolution, car il faut gérer des nouveaux comportements des widgets natifs.

En tout cas, on constate que :

• Wx utilise l'approche Qt pour un certain nombre de Widget avancés, qui ne sont pas communs à toutes les plate-formes et doivent être fait en natif.
• Qt utilise l'approche de Wx pour un très petit nombre de briques, où le choix est proposé entre la version par défaut de Qt ou la version native: dialgue de fichier, system tray, et je sais plus quoi d'autre.

Tout le monde peut donc se faire des bisous, tout va bien.

au temps pour moi…