moi1392 a écrit 740 commentaires

Ça me parait un peu compliqué, mais ça marche !
Moi, je me serait contenté d'une liste chainée simple de pointeur de fonctions dans le genre :

struct layer {
    void (*next_func)(struct layer*, ...);
    struct layer* next_layer;
};

et derrière, tes fonctions deviennent :

void l1(struct layer* lay, ...) {
    ...
    lay->next_func(lay->next_layer, ...);
}

Tu peux facilement ajouter un truc au milieu de ta couche en ajoutant une fonction au milieu de liste layer.

Et sinon, juste pour le fun :

struct x {
    int a;
    int b;
};

struct x X;

Et admettons :

X est à l'adresse 0x14C4
X.a est à l'adresse 0x14C8
X.b est à l'adresse 0x14CC

chez moi, l'adresse de X.a est la même que X ;)

J'ai appris cette semaine que Debian était entrain (tout doucement seul experimental le fait pour le moment) de remplacer libstdc++ par libc++

j'ai vu passer aussi la news, je me suis mis un marque page dessus, mais je n'ai pas encore eu le temps d'aller voir ça tranquilement (Et à priori, c'est pas pour ce week end non plus…)

D'ailleurs j'ai été assez surpris, et je suis curieux de savoir quel est l'objectif de ce remplacement.
Dans tous les cas, si c'est une lib c++ standard qu'ils veulent, cela va être compliqué de faire sensiblement moins gros, à part peut-être en la splittant en plusieurs biliothèques un peu à la boost ?
Ça pourrait être une idée intéressante pour les projects c++ embarqués qui veulent le minimum de dépendances.

Si j'arrive quand même à trouver le temps d'y jeter un œil ce week end, je posterai sur ce fil de discussion ce que j'en ai compris.

Dans le contexte, j'aurais plutôt dit les "coinnaisseurs".

Sinon pour ce qui est du portage vers c++, il y a des bons et des mauvais argument contre que je vois beaucoup.

Pour les bons, je dirais l'emprunte mémoire de la libstdc++ qui est plutôt gênante pour les systèmes embarqués. En même temps je pense que la cross-compilation marche pas trop mal et que cet argument est plus valable pour gdb que pour gcc.
Le second est l'abi c++ qui n'est pas terrible et qui a du changer à plusieurs reprises.
Mais on peut raisonnablement supposer qu'un compilateur c++ soit livré avec le runtime c++ qui va bien.

Ensuite, pour les mauvais arguments, j'ai toujours du mal avec les critiques sur c++.
Oui oui, on peut faire des tas de choses horribles avec, mais il est quand même fourni avec une librairie standard pas trop mal, surtout si on prends boost avec (pas standard ok, mais vraiment pratique pour pas mal de choses)
Et puis je suis désolé, mais travailler avec des structures de données et des concepts définis dans un langage, ça reste toujours mieux que de refaire sois même (dans le même langage, à peu de choses près) une implémentation objet (des tableaux de pointeurs de fonctions, héritage par inclusion ou copie, beurk), des conteneurs pour chaque type (pas de généricité du code, beurk)

À un moment il faut arrêter les conneries, en 1995, les compilos et librairies standard n'étaient peut-être pas au point, mais ça n'est plus le cas depuis bien longtemps.
D'autant plus que l'effort pour passer de C avec une implémentation moisie d'un concept objet (d'un point de vue utilisabilité et maintenabilité du code) à du c++, c'est pas la mort.

PS: c'est mon premier flamewar c/c++ et c'est moi qui le lance en plus, c'est pas beau la vie le vendredi ?

je me réponds à moi même, je viens juste de lire cet article du monde : http://www.lemonde.fr/technologies/article/2012/08/16/la-grande-bretagne-determinee-a-extrader-julian-assange_1746459_651865.html

Où il y a ce détail intéressant : "la Suède et la Grande-Bretagne ne peuvent pas, en raison des lois locales et européennes, extrader un individu "vers un pays où le prévenu risque la peine de mort"."

C'est vrai que c'est une loi européene, et je ne sais pas s'il est possible de tricher avec une astuce du genre "garanti qu'il n'y aura pas de peine de mort appliquée, donc vous pouvez l'extrader"

Ou alors on peut imaginer que la personne étant australienne, la suède ne veut plus d'elle sur son territoire, donc elle l'extrade dans son pays d'origine, où il ne risquer pas la peine de mort, puis de là, plus de soucis pour l'envoyer aux états unis.

Pourquoi? Quel motif? Pourquoi la Suède et pas la GB?

Sur ce point, mes sources sont assez faibles. De ce que j'en ai lu, les accords d'extradition sont plus facile depuis la suède que depuis l'angleterre.
Maintenant, l'effort extraordiaire qui a été mis en place pour cette affaire laisse quand même peu de doute sur le fait qu'il ne s'agit pas que d'une affaire de viol.
C'est un peu comme si on faisait faire des test ADN pour un vol de scouter, personne ne ferait ça…

Non, je ne comprend pas pourquoi on dit qu'il sera extradé si il se retrouve en Suède. Pourquoi la Suède spécialement? et si c'était la France?

Il n'est accusé d'aucun crime en france, donc pas possible de demander son extradition vers la france pour pouvoir l'extrader ailleurs ensuite.

Bizarrement, aucun journaliste ne l'explique, j'attends des journalistes qu'ils expliquent,

Je n'ai pas fait de recherche approfondies sur le sujet, donc ce que je dit reste des suppositions basées sur ce que j'ai pu lire et mes suspicions entretenues par le caractère plutôt exceptionnel de l'affaire.
Je pense que tu peux quand même admettre qu'annoncer aller chercher une personne dans une ambassade pour l'extrader parce qu'il à fait des galipettes sans capote, c'est plutôt surprenant ! Et ça laisse quand même planer un doute sur la légitimité réelle de l'affaire.

ce qui est sous entendu, c'est que le procès en suède n'est qu'une excuse et que peu importe le résultat, il sera extradé vers les étas unis.

Perso, je suis assez surpris de l'effort mis en place pour cette histoire, même si dans le cas où j'aurais été une jeune demoiselle violée, j'aurais certainement grandement apprécié la procédure, je doute TRÈS fortement qu'elle aurait été mise en place dans un autre contexte.

Le second point est qu'au états unis, il n'aura pas de procès équitable du tout (voir pas de procès du tout…), et pour ce point, il y a pas mal de signes (voir d'exemples) qui tendent à le confirmer, à commencer par le sort du soldat qui est accusé d'avoir fourni ces informations.

Tu comprends mieux ou tu as besoin de plus d'éclaircissements ?

Le problème d'OpenGL est que les très vielles fonctions sont toujours supportées, ça fait beaucoup de code dans les pilotes, car plus rien de tout ça n'est cablé directement dans les puces graphiques, et du coup ça augmente de beaucoup l'emprunte mémoire de la libGL (de plusieurs Mo, y'a qu'à voir la libGL de nvidia ou amd), pour de l'embarqué, c'est complètement redhibitoire.

En plus, y'a régulièrement des bugs et des soucis de performances liés aux anciennes fonctionnalités (je m'en tape de temps en temps au boulot)

À vérifier tout de même, mais il me semble que du code OpenGL ES est 100% compatible OpenGL, sauf la partie connexion avec le système de fenêtres.
Dans le cas de X11, c'est glX qui fait ça. Pour OpenGL ES, c'est EGL, et c'est sensé être une couche d'abstraction unique pour toutes les plateformes.

Pour faire la même chose avec OpenGL, il y a OpenGL 3 core (à partir d'OGL 3.1) qui déprécie toutes les vielles fonctionnalités des entêtes avec le défine qui va bien.

Donc le mieux je dirais c'est soit de coder en OpenGL ES si on vise aussi l'embarqué, soit en OGL3 Core si on est exclusif au desktop.

Castré n'est pas vraiment le mot, OpenGL ES est sensé contenir une unique version des fonctionnalités de base pour avoir un rendu 3D, en gros les plus performantes et les plus proches de la carte graphique.

L'intérêt pour l'embarqué et qu'on supprime énormément de code utilisé pour maintenir la compatibilité avec les fonctionnalités "habituelles" d'OpenGL (en gros, OpenGL < 3)

Donc ça fait moins de code, mois d'espace disque et d'espace mémoire utilisé, et en bonus, on force les utilisateurs à utiliser une API plus proche du matériel qui, à priori, est plus performante.

En simplifiant, OpenGL = OpenGL ES + fonctionnalités supplémentaires dépréciées (fixed pipe, direct mode, display lists, …) + des fonctions utilitaires en plus.

Ou alors tu utilises ton cerveau, c'est bien aussi.
J'ai plusieurs adresses de courriel chez google, aucune adresse de récupération ni numéro de téléphone.
Si j'oublie mon mot de passe, c'est fichu.

tu veux dire : sed s/logiteque/logitheque/g

(éléphants, frigo, toussa…)

ils ont misé en 2008 sur Qt

Ils n'ont misé sur rien du tout en 2008, ils ont fait un peu de Qt, un peu de gtk, un peu de megoo (je sais plus comment il s'appelait avant la fusion avec l'os d'intel), une peu de symbian, un peu de tout et de rien.

Au moins, là, leur stratégie est claire et bien définie, le seul soucis c'est qu'elle n'est pas efficace (du moins, pour l'instant, pour l'avenir on n'en sait rien)

S'il avaient vraiment misé de tout leur poids sur megoo/qt à l'époque, je ne sais pas si ça aurait marché, mais on s'en serait au moins rendu compte.

Peut-être que d'un point de vu business Qt ne rapporte rien ?

Il me semblait que trolltech ne marchait pas si mal, en plus il y a plusieurs boites autour de Qt (kdab, par exemple), c'est qu'il doit y avoir de l'activité.

J'ai l'impression qu'il en manque un là…

Je te conseille de faire une démo argumentée à ton boss, à qui tu démontreras ton gain de productivité avec Linux.

Mon boss viens me demander de faire des recherches pour lui…

Et dans certains cas, il les fait lui même… dans un linux dans une machine virtuelle sur son windows !!!!
Oui oui, il préfère ça à l'outil de recherche integré dans vs 2010.

Ah oui, par contre, faudra des vrais chiffres avec la même chose de chaque côté, et pas une subjectivité des plus douteuses.

Je pense que la subjectivité d'attendre 5 fois plus n'est pas si douteuse que ça, et mêem si en vrai c'est notre méchante subjectivité qui nous à donné cette impression et que c'est que 3,8 fois plus, ça reste pas si mal.
Fais le test toi même, et tu verras.

Je te donne des chiffres sous linux que je viens de faire là :
à froid (pas vraiment en fait) une recherche dans 20000 fichiers cpp/h, 35 secondes. La même juste après, 13 secondes.

commencez par arrêter avec vos mensonges

Menteur toi même ! T'as qu'à faire le test et tu verras.
Ou mieux, tu viens et je te montre, et après tu t'excuses publiquement de m'avoir traité de menteur, ça te va comme deal ?

Mon petit doigt me dit que tu utilises un OS pre-Vista

a) le dernier windows que j'ai utilisé, c'est 2000, je te parle des 2 collègues de mon bureau qui sont sous 7 professionnel avec les dernières mises à jour.
Ils sontjuste à coté, les tests sont super simple tu sais…
Et une fois encore, c'est pas parque que vous avez un super lien qui dit que c'est trop bien que c'est le cas.

sur un repertoire avec des sous-repertoires et milliers de fichiers s'execute enormement plus rapidement la 2eme fois que la 1ere

Ça reste ultra plus lent que chez moi les 2 fois.

Super, et tu as regarde pourquoi ton espace d'addresse est fragmente ? T'es sur que ce n'est pas parce que tes dlls sont loades a 48 endroits differents et fragmentent l'espace plutot que l'allocateur ? Si t'es sur un OS pre-Vista, LFH n'est pas l'allocateur par defaut non plus, faut ajouter le setting pour.

hum… comment dire…

Bref, tout ce que tu me dis, avec les infos que tu me donnes, me dit que tu fais une observation a 15 kilometres d'altitude, vois un resultat qui ne te plait pas, mais tu ne sais absolument pas ce qui cause le comportement que tu vois et tu supputes.

Oui ?? Et ?? C'est exactement ça le problème, sur ma machine, même à 32 kilomètres d'altitude, j'ai aucun souci, sur les autres, il y a ces soucis peu importe l'altitude.
Et effectivement, je n'en connais pas la cause, mais je sais que :
1) avec un système de fichier et un vfs performant, ils n'y sont pas.
2) avec une gestion de la mémoire performante, ils n'y sont pas.
J'en conclu donc avec un raisonnement ultra poussé qui dépasse de très très loin les capacités cognitives insoupconées de l'huitre, que windwos n'a aucun de ces deux points.
Je pense que ça n'est pas trop fantaisiste comme supputation.

Pour faire simple, certains de mes collègues viennent me demander de faire les recherches pour eux.

Et au passage, j'ai la machine la plus vieille dans mon bureau, donc la moins performante, moins de coeurs d'exécution (on pourrait en parler aussi de ça tiens.. l'ordonnancement et la gestion des multiprocesseurs/multicoeur pour les taches en parallèles) et moins de ram.

Tu plaisentes j'espère… Les accès disques physiques sont nul à chier, et ça même toi tu dois le savoir, en plus, il n'y a aucun cache, sous linux, tout accès disque est gardé en cache si la memoire est suffisante, et ensuite, tous les accès suivants sont fait par la couche vfs du noyau. Exemple simple, je me logue sous KDE, c'est lent… Je me délogue et je me relogue, ça va 10 fois polus vite, et je n'exagère pas sur le 10 ! Fais ça avec windows !

Comme exemple concret, j'ai mon boulot, TRÈS GROS (et c'est un euphémisme) logiciel multiplateforme avec plein plein plein de plugins, les accès disque sont plus lent, point à la ligne, je peux pas faire mieux que le dire, ou alors je peux vous vendre une licence si tu veux vérifier toi même.
Ensuite, regarde les temps de compilation pour un gros projet par exemple, et ce n'est pas que du à la lenteur excessive du compilo !
Et encore, fait une recherche dans les fichiers !! Pour rechercher dans les sources de mon projet, un outils codé en C qui utise des reg exp perl donne un résultat de l'ordre de 30 secondes sur tout le projet, sous windows, l'outil "optimisé" de vs 2010 qui ne recherche que dans les fichiers de la solution… Et bien je ne sais pas, personne n'a jamais tenté, mais pour un seul plugin (j'en ai 30 dans mon espace de travail, mais pour temperer, il n'y en a que quelques-uns de vraiment très gros, je dirait en taille, il fait 1/5 du total), il dépasse la minute !! La bonne blague !

Enfin, parlons-en de l'allocateur et de sa tendance à fragmenter… Tu dois savoir que windows x86 donne 2 Go de l'espace pour la partie utilisateur des process et 2 pour la partie noyau, et bien dans la pratique, on n'a JAMAIS réussi à dépasser les 1,5 Go… Et souvent à partir de 1,3 Go, ça commence à sérieusement être foireux pour les grosses alloc de plus de 100 Mo…
Sous linux, jamais un soucs d'allocation tant que je demande de la mémoire disponible !
Et c'est pas parce que ton allocateur s'appelle "L'Allocateur Qu'Il Est Trop Bien Pour Pas Fragmenter (tm) (r) (c) (trololil)" qu'il fragmente pas. À ce petit jeu, j'ai mangé des gateaux à l'huile de palme "raffiné" aujourd'hui…

un écart de 4% en fps à 300 fps, je le met dans les marges d'erreur de la mesure.

Pas forcément, si le test est correct et répétable, je pense que la différence est vraiment là, mais je pense aussi que dans d'autres contextes (autres jeux, autre load du système, autre utilisation des ressources) le résultat est certainement inversé.

Après, ce que je ne sais pas, c'est si la balance est plutôt équilibrée, ou si elle penche pour un os ou l'autre.
Et pour ça, quelques portages ne suffiront pas, car les jeux sont très optimisé pour windows (pour contourner les limitations que j'ai énoncé dans mon précédent post, je m'en doute car on fait pareil dans notre boite, on dépense une énergie considérable à pallier aux défauts de perf de l'allocation mémoire et de l'accès aux fichiers sous windows) donc il faudrait le temps que les jeux soient vraiment conçus et optimisés à la base pour du linux pour voir s'il y a une réelle différence (j'en reste pas convaincu, une fois tout chargé, ça reste limité par la puissance de calcul du processeur, de la bande passante mémoire et de la carte graphique essentiellement)

Ah ben voila… J'ai parlé que pour du jeu ici. On parle de ça non?

Oui oui, on parle de ça, j'avais compris le contraire dans ton premier post, c'est pour ça que j'ai réagi :)

Linux n'est pas pire que Windows (et pas mieux)

Heeuuu… je ne suis pas tout à fait d'accord là dessus…
Faudrait quand même pas oublié les performances du système de fichier, en particulier la gestion du cache disk absolument misérable sous windwos (bien qu'annoncée comme améliorée et enfin performante à chaque nouvelle version…)
La gestion de la mémoire par l'os, ainsi que la fragmentation due à l'allocateur par défaut de la libc.
Et des tas d'autres choses donc je ne fait pas l'expérience 15 fois par jour au boulot (chiffre non contractuel)

Bon, je ne pense sérieusement pas que ce soit ces choses qui font la différence dans ce cas précis, mais dire qu'il n'est pas mieux, faut qund même oser, ou alors n'avoir jamais développé d'application lourdes mutliplateforme (oui, c'est un troll pas déguisé du tout)

Gnome nous montre une nouvelle foi la voie

Désolé, c'était trop tentant…

j'ai acheté un jeu sous Linux (à l'époque il était déjà vieux) : NeverWinter Nights, il contient tout ce que tu décris et qui pose habituellement problème : musique et sons, 3D, binaires sans empaquetage typique pour une version précise d'une distribution. Et pourtant, 10 ans après, ce logiciel fonctionne toujours sous Linux ! La 3D, le son, les binaires statiques (et ils ont rajouté les bibliothèques type SDL dans un sous dossier).

Il est marrant ton exemple, car dans exactement le même cas, j'ai eu un soucis avec la libsdl fournie avec, du coup, je l'ai juste virée pour qu'il utilise celle de mon système, et ça marche !!

Au passage, j'ai eu exactement le même problème avec World of Goo.

Et dans les deux cas, le crash avait lieu dans sdl audio, à l'initialisation de …pulseaudio !!

Si Windows8 se plante, les gens resteront sous Windows7 en attendant Windows9

La différence (du moins, c'est mon avis) majeure est que les gens ne voudront plus non plus de windows 9, car l'intérêt, et donc la vente de système pour le desktop diminue fortement au profit de celle pour les smartphones et tablettes.

Donc si le virage échoue, on peut penser que ms peut chuter assez (relativement…) rapidement ! Et je pense que c'est ce qu'ils se disent chez eux aussi, c'est pour ça qu'ils mettent toutes leurs forces dans ce virage.

Pour moi, si ça échoue, microstof deviens "gros" acteur de l'informatique, et plus l'acteur ultra dominant, dans les 5 à 7 ans à venir. (Oui, j'ai envie de faire ma madame soleil moi aussi, surtout qu'il y en a pas mal aujourd'hui)

Le mot est gentil, on a que des charlots à ce poste là.

sauf la schtroumpfette…

Non mais sans blagues… Qu'est ce qu'on s'en fou ???

Apparement, le type l'a fait exprès, mais imaginons un peu qu'un type tombe sur cette constante, ou une autre qui puisse avoir une signification quelconque, complètement au hasard, faudrait la changer parce qu'elle veut dire quelque chose dans une langue avec une interpretation et un codage particulier ???

Faut arreter les conneries un peu, pour moi, c'est un nombre en notation hexadecimale qui sert surement d'identification de service dans un protocole réseau quelqconque, et une fois compilé, il ne représente rien de plus qu'une id pour identifier quelque chose.

générer un code cyclique redondant de type CRC-32

J'ai plutôt l'habitude d'entendre "code de redondance cyclique".