TImaniac a écrit 6420 commentaires

Depuis Java5 la généricité permet de s'affranchir dans pas mal de cas du cast.
Ah que non non pas du tout, en Java5 le compilo met juste les casts à ta place, c'est du joli sucre syntaxique et les casts sont toujours nécessaire, les objets étant toujours stockés sous forme d'Object, ce qui a des graves conséquences en terme de performance lorsqu'on met un type primitif dans un truc générique.

L'utilisateur de desktop s'en fou royalement de pouvoir désinstaller ces 2 softs, c'est pas pour les quelque Ko octets qu'il prennent... On n'est pas obligé de les utiliser et on peux mettre d'autres softs en remplacement donc bon.

Par contre c quoi le rapport avec le look de OOo 2.0 ? (cf ton post suivant)

ou de faire une partie à trois avec ma nana et sa meilleure copine
En même temps si c'est sa meilleure copine ca se comprend :)

Oué donc ok le compilo est informé lors d'une 2ème passe après profiling. Mais dans ce cas bien précis du kernel linux, fournit tel quel, me semble pas que la procédure standard de compilation utilise cette méthode, si ?

MSN Messenger et Outlook peuvent être virés, contrairement à WMP.

Si on lit ce qui marqué par ici : http://www.clubic.com/actualite-17825-windows-xp-sans-wmp-en-janvie(...)

"l'avocat général du géant du logiciel PC s'est finalement prononcé. Il a ainsi annoncé que la firme de Bill Gates et de Steve Ballmer proposera une version de Windows XP sans Windows Media Player en Europe à partir du mois janvier."

Donc apparement ce sera effectif.

Reste à savoir si ce windows contient le SP2, parcque s'il ne le contient pas, toute installation du SP2 apportera WMP par la même occaz.

celà peut venir de la vidéo en elle-même, auquel cas tu peux le vérifier avec une autre vidéo.

puisque dans la plupart des cas le programmeUR met naturellement le test dans le "bon sens"

Merci pour cette piqûre de rappel :)

En tout cas on est bien d'accord que dans ce contexte la prédiction de branchement ne permettra pas d'optimiser le fork(), celui-ci n'apparaîssant pas assez souvent (c'est ce que je voulais dire même si je me suis un peu enmêler les pinceaux ^^)

Après je n'avais pas pensé qu'effectivement le fait de mettre le test dans un sens ou dans l'autre changeait le chemin "par défaut", et dans ce cas effectivement le compilo fournit là une information importante suivant le code généré.

Mais comment le dire au compilo ? Même après instrumentation ? Le compilo ne pouvant pas le deviner lui-même (c'est une info dynamique), il faut faire l'optimisation à la main ? (en gros changer nous même la condition ?)

Effectivement dans ces conditions il peut aller tout droit, à vrai dire j'avais mal compris ta phrase je pensais que tu voulais carrement sauter les conditions (mais bon j'aurai dû réfléchir un peu plus)

Après au niveau des perfs tu veux comparer avec quoi ? Un programme qui fait en sorte que le proc se trompe systématiquement de branchement ? Effectivement là le proc risque de devoir systématiquement vider son pipeline, ça va pas être terrible :)

Enfin de toute façon pour en revenir au problème de départ, celà ne change strictement rien, que ce soit if+goto ou if+fonction, les problèmes de prédictions sont les mêmes. Et heuresement on n'a généralement pas besoin d'effectuer l'optimisation que tu suggères, puisque dans la plupart des cas le programme met naturellement le test dans le "bon sens" (sous entend : on effectue un jmp si pas normal), mais il est vrai qu'il faut mieux en être conscient :)

quels sont les modes de sorti proposés ?
t'as essayé avec un autre lecteur ?

Pour info dans le cas de l'Itanium c'est bien le compilateur qui s'en soucie et qui va (tenter d')annoncer au processeur "tiens compte du branchement qui suit".
Vi mais c'est pas tous les jours qu'on code sur Itanium... D'ailleur si j'ai bien suivit c'est un peu une "horreur" à optimiser ce bousin... Enfin c'est ce qui fait son charme :)

l etablit des statistiques sur les instructions executee dans le passe et il s'en souvient quand il revient dessus?
Bah me semble qu'il y a des architectures qui cherchent à prédire un branchement en fonction des instructions précédentes : c'est pertinent dans une boucle ou par exemple la condition de fin n'est vérifiée qu'une fois, mais je voulais dire que je n'était pas sûr de l'intérêt du truc dans le cas d'une fonction.

Effectivement il peut être intéressant de chercher à indiquer au compilo quelle partie du code risque de brancher pour le "guider" (puisque n'étant pas dans un boucle il aura du mal à prédir), mais comment l'indiquer au processeur ? (à part avec l'Itanium)
Quelle instruction du langage utilises-tu ? Ton code risque d'être spécifique à un compilo et/ou une plateforme...
Enfin pour moi y'a qu'un seul truc dans les langages de programmations qui indiquent ce genre de comportement : les exceptions.

Si tu as plus d'infos sur ce sujet ça m'intéresse.

http://www1.mplayerhq.hu/homepage/design7/codecs.html(...)

ceux qui t'intéresse sont les Quicktime. Le "essential" regroupent à peu près tous les codecs utilisés.

Ils sont gentils ces polonais :)
C'était pas déjà eux qui avait fait chutter la majorité qualifiée ?

c'est court, donc plus facile à lire
Ben entre une méthode qui fait quelques centaines de lignes (comme c'est le cas dans la méthode copy_process prise en exemple plus haut) avec des goto et une dizaine de méthode de quelques lignes, je préfère largement la 2ème solution, pour moi beaucoup plus lisible sur ce que fais chaque bout de code :)

c'est une solution connue, elle est donc facilement lisible par tout programmeur ayant un minimum d'expérience
Ma méthode est également classique je n'ai rien inventé :)

a ne mets pas en jeu la moindre (méta) donnée (explicite ou même implicite comme dans ta solution), ça ne joue que sur du contrôle
Elles sont où mes méta-données ? C'est le fait de gérer une pile ? Et ? C'est quoi le problème ? On n'a qu'une dizaine de méthode à tout casser, donc je penses pas que ce soit négatif de l'utiliser ici.

Ainsi, le cache d'instructions cpu ne se remplit pas avec du code ~jamais exécuté : on gagne effectivement en performances.

Ca ne change strictement rien : dans mon exemple on fait l'appel à la méthode de traitement d'erreur avec autant de probabilité qu'avec un if+goto.

Ensuite ce n'est pas au compilateur de se soucier de ça : le processeur gère lui même un cache d'instruction en fonction de la fréquence d'apparition des instructions, et tu ne pourras jamais exécuter le code tout droit, il faut obligatoirement faire les tests de nullitée. Sans compter que de toute façon le processeur évaluera peut être les 2 branches s'il a rien d'autre à foutre (faut bien remplir le pipeline).

Ensuite vu que chaque proc y vas de sa méthode de cache, je vois pas trop ce que tu vas indiquer au compilo de faire...

Enfin je finirais par faire remarquer que je ne suis pas sûr que l'appel à fork soit si fréquent pour que le proc le mette dans son cache d'instruction...

Enfin tout ça pour dire qu'un if+goto ou un if+appel ne change rien au niveau des perfs si la condition n'est quasiment jamais rempli (ce qui est vrai la plupart du temps)

allez une autre méthode à base de fonction, qui fait que chacun peut gérer son annulation comme il l'entend :

bool action1(){
if(!do_stuff() || !action2()){
cancel_stuff();
}
}

bool action2(){
if(!do_stuff() || !action3()){
cancel_stuff();
}
}

etc.

on utilise ici la pile des appels.
avantages : le code est beaucoup plus lisible et maintenable : chaque action contient également le traitement de l'annulation qui n'est pas éparpillé à l'autre bout du code. SAns parler du fait qu'on n'évite de se retrouver avec des méthodes de plusieurs centaines (!!!!) de lignes, qui pour la lisibilité n'est vraimetn pas terrible.

En fait il suffit de looker tous les algos qui s'occupe de gérer des transactions atomiques : ils se passent très bien de goto et c'est propre.

effectivement c'est peut être plus verbeux mais tellement plus explicite : le nom de la méthode gestion_erreur indique déjà clairement ce qu'on fait : on traite une erreur; avec le goto je ne savais pas du tout ce qu'il y avait au bout du goto et ce qu'il faisait.

Après c'est vrai qu'en C y'a ce foutu problème d'absence d'unité d'encapsulation obligeant à mettre les variables en globales si on ne veut pas toutes les passer en paramètre. Une solution pour éviter la lourdeur serait de les encapsuler dans une structure.

par contre le "moins dupliqué" je ne suis pas d'accord", le "moins lisible" je dirais plutôt "moins verbeux". Mais si on part de ce principe on code en assembleur, c'est vrai quoi, au moins les instructions ne sont pas verbeuses et on peut mettre des jump partout !

Si tu le mets pas dans une autre fonction t'es obligé d'utiliser un goto de toutes façons.
???

Enfin comme quoi c'est possible de s'en passer de ces goto, c'est souvent plus verbeux mais on ne perd rien en duplication et pas grand chose en perfs.

Oué enfin je suis pas non plus un hacker fou pro du C :)
Autant je comprends à peu près l'intérêt lorsqu'on gère une pile (effectivement lorsque les allocations/libérations sont différentes), mais parofis je captes pas trop l'intérêt (notamment lorsque les goto ne s'enchaîne pas :
exemple :
fork_out:
1142 if (retval)
1143 return ERR_PTR(retval);
1144 return p;

pourquoi ne pas mettre ca dans une fonction ? à mon avis le compilateur la inlinera très bien.

sinon de manière plus générale j'ai envie de faire :

gestion_erreur(code){
switch(code){
case ERROR_ALLOC_TRUC:
do_stuff();
case ...

}
}

celà cache implicitement des gotos mais c'est déjà plus élégant que la suite :

ad_fork_cleanup_namespace:
1147 exit_namespace(p);
1148 bad_fork_cleanup_mm:
1149 if (p->mm)
1150 mmput(p->mm);
1151 bad_fork_cleanup_signal:
1152 exit_signal(p);
1153 bad_fork_cleanup_sighand:
1154 exit_sighand(p);
1155 bad_fork_cleanup_fs:
1156 exit_fs(p); /* blocking */
1157 bad_fork_cleanup_files:
1158 exit_files(p); /* blocking */
1159 bad_fork_cleanup_semundo:
1160 exit_sem(p);
1161 bad_fork_cleanup_audit:
1162 audit_free(p);
1163 bad_fork_cleanup_security:
1164 security_task_free(p);
1165 bad_fork_cleanup_policy:

Ce que se tuent à expliquer les utilisateurs du p2p militant c'est que justement ce genre de comparaison est totalement foireuse de part la matérialisation du support et la nature du contenu (culturel).

De manière générale j'ai l'impression que l'utilisation du goto dans ce cas précis tend plutôt à montrer que le programmeur ne s'est pas pas rendu compte qu'il gérait une "pile" et qu'elle peut très bien être simulée avec un tableau comme je l'ai fait dans mon exemple.

A vrai dire je te rejoins en ajoutant que dans la rubrique "bonnes pratiques" l'utilisation des continue et des break est également déconseillé parcque justement celà nuit à la lisibilité : on préfèrera un invariant de boucle.

void * trucs[4];

int i = 0;

while(i<4){ //ALLOC
truc[i] = malloc(stuff);
if(truc[i] == null) break;
i++;
}

if(i<4) //ERROR ALLOC
while(i>0){
i--;
free(trucs[i]);

}

u veux une explication de l'intérêt de la chose? Ou tu as compris le truc?
Désolé, aux erreurs de programmation prête il y a toujours moyen de faire autrement, et là en l'occurence c'est encore plus court ;)

Les profs t'apprennent que les variables globales c'est mal, que les goto c'est mal, etc, parce qu'ils t'apprennent mal.
Nan c'est juste que dans 95% des cas c'est mal et qu'il faut toujours essayer de s'en passer (ça ne coûte rien d'essayer)

Evidemment tu trouveras sûrement un cas où c'est pratique/concis/etc. mais les profs étaient là pour nous expliquer les dangers du schmurck, alors dire qu'ils apprennent mal c'est un peu fort. C'est pas tous les jours qu'on code un kernel ;)

Comme l'indique leur nom les exception sont "exceptionnelles" et ne doivent en aucun cas être utilisé comme une possibilité de transmission de message comme une autre.

Même si elles peuvent apparaîtrent n'importe où, elles ne permettent pas de se brancher n'importe où dans le code contrairement au goto, qui de plus peu être utilisé à tout va puisque son utilisation n'est pas limité par sa sémantique.

L'exemple de la programmation objet comme tu dis est un parfait exemple de style de programmation où le goto devient complètement inutile et déconseillé : les méthodes sont réduites à leur plus simple expression, ne font qu'un dizaine de ligne maximum, alors l'intérêt d'un goto là dedans... Et si tu uitlises un goto pour sortir d'une méthode tu te retrouves avec du code spaghetti indéboggable et tu te fais virer par ton chef de projet qui fait de la programmation par aspect ete qui ne captes pas pourquoi son code à lui n'est jamais exécuté...

Les goto pour la gestion des erreurs sont bien plus puissants, lisibles et compréensibles qu'un break/continue/return posé au milieu de 3 boucles imbriquées ;
Ah bon tu remplacent le mot break/continue/return par un goto et tu comprends mieux ? Je captes pas... ok y'a moins de lettres... break/continue/return sont des cas particulier de goto, ont une sémantique et une utilisation précise qui fait que tout le monde les comprend, notamment le compilateur (et c'est pas négligeable).

Je comprends pas bien ton raisonnement :
on fait un CD pour payer le matos pour faire le CD (???)
ca se mord la queue...

Un artiste qui veut faire un CD est un artiste qui veut promouvoir sa musique, pas pour payer le matos nécessaire à faire le CD. Il est vrai qu'avant celà revenait à très cher, mais actuellement c'est devenu dérisoir.

Mais ça reste un moyen de publicité (auquel cas je ne vois toujours pas pourquoi il faut le faire payer), ou un moyen d'expression : auquel cas je comprend qu'on fasse participer aux frais de production de support. Mais là en l'occurence on n'a plus de support, ou tout du moins il ne coûte quasiment plus rien, le mixage ne requiert plus un ingénieur (ou alors c'est qu'il faut cacher l'incompétence de l'artiste) et pas besoin de masterisé un CD pour se faire de la publicité : l'auditeur ne s'arrête pas à ça.

PS : il y a des enregistrement gospels qui n'ont pas été fait en studio et qui ont un certain charme sans empêcher d'apprécier à sa juste valeur l'artiste qui interprête.

Sauf que pour 95% des gens ca se résume à :

"j'ai pas assez, donc j'achète pas (et je n'achèterai jamais)."
"Le peu que j'achète reste des valeurs "sûres" et tendances que j'entend tous les jours à la radio ou sur TF1/Nike/Bouygues/ft.com(TM(c)(R))."
"La diversité culturelle ? Désolé j'ai pas 15 euros à mettre pour prendre le risque d'écouter un album d'un artiste que je ne connais pas."

Voilà en gros comment réagissent la plupart de la masse des consomateurs de culture.

Le p2p est une une chance inouïe d'ouverture culturelle, de découverte.

Le vol c'est quand tu piques un CD à la fnac : tu voles un support, un livret.

Quand tu télécharges tu ne viole qu'une propriété intellectuelle dont on se demande encore comment les majors ont réussi à s'attribuer tous les droits. Télécharger, c'est contester cet état de fait, cette prise en otage de la culture par 4 ou 5 grands groupes aux objectifs commerciaux complètement contradictoire avec la cultture.