Troy McClure a écrit 2213 commentaires

je ne peux que plussoyer c'est un vrai plaisir d'ecouter cette video ! Il est vraiment fort ce linus

On est d'accord.

Je n'avais pas entendu parler de ce que tu cites sur le "range-based for loops" mais si c'est vraiment inclu dans c0x c'est super.

Au moins le foreach de Qt aura eu le mérite de mettre en évidence qu'il y avait une vrai demande pour ce genre de construction. Ce qui n'etait pas évident au départ; a chaque fois que j'ai vu ce sujet abordé tous les c++-gurus se braquent sur le mode "la stl est parfaite tu pas besoin d'autre chose"

y'a aussi un #pragma ivdep qui existe sur certains compilos et qui dit explicitement que les iterations de la boucle qui suit sont indépendantes, mais je crois que gcc ne le connait pas

C'est l'idiome qui veut cela et c'est quand même l'idiome le plus standard du C++

Oui et 99% du temps on travaille sur le conteneur entier au lieu de ne travailler que sur une partie. D'ou l'interet d'un foreach qui ne te redemande pas systematique de preciser les bornes. Ou bien d'avoir un concept de "paires d'iterateur", enfin n'importe quoi qui permette de réduire le nombre de caractères tapés et surtout le risque d'erreur ( genre si le begin et le end sont pris sur deux conteneurs differents).

On rentre dans les boosteries, c'est déjà une bibliothèque supplémentaire à utiliser. On peut aussi pinailler sur le fait que nommer l'element courant "_1" soit vraiment elegant. Ou bien que c'est plus joli d'imbriquer des foreach "à la Qt" que d'imbriquer deux std::for_each l'un dans l'autre.

Comme je le dis plus haut, c'est totalement sous optimal, tu es obligé de rappeler le type de ton conteneur pour indiquer le type des iterateurs (et des fois ça peut etre vraiment long, source d'erreur), et d'appeler explicitement begin et end.

pose toi la question pourquoi personne ne veut utiliser ce truc: ce que propose Qt est pratique. std::for_each ne sert à rien, et considerer ça comme un equivalent du foreach de qt je trouve que c'est un peu pousser grand-mêre dans les orties.

Le foreach de qt est optimal dans le sens ou il minimise la redondance de ce que tu as a taper.

Quel est l'équivalent standard du foreach de Qt ? Le fait est qu'il n'y en a pas, et que si Qt l'a introduit c'est bien parce que ce genre de truc est diablement pratique

Le milieu seulement sera vectoriel avec les accès aligné.

Si il n'y a qu'un operande je peux le concevoir, mais quand il y a deux operandes (comme dans saxpy), ou plus, ça devient très compliqué, à moins d'en provilegier une et d'accèder aux autres de façon non alignée.

Au contraire, les adeptes du C++ moderne adorent C++ et n'aiment pas trop Qt.

Qu'est ce que le c++ moderne au juste ? un espece de machin "tout templates" hyper lourd avec des messages d'erreurs inintelligibles qui se déplient sur 500 lignes, un langage qui demande 2 go de ram et 10 minutes pour compiler un programme de deux lignes tellement on abuse des templates et on les pousse dans leurs limites ? C'est vraiment devenu un sport de faire les construction les plus tordues et de triturer le langage dans tous les sens, et je ne suis pas sûr qu'à la fin la lisibilité, la maintenabilité, et même la performance soient au rendez-vous.

> si c'est de l'allocation dynamique t'as intérêt à ce que ce soit aligné "de base".

C'est un bon exemple, puisque ce n'est pas le cas: sous linux, malloc renvoie des addresses alignées sur 8 bytes, pas sur 16, donc on a une chance sur deux d'avoir un buffer mal aligné (sous macos par contre malloc renvoie toujours un buffer bien aligné).

Maintenant il y a des situations où avec la meilleur volonté du monde, le compilateur ne peut pas savoir que les addresses qu'il recevra seront bien alignées. Si par ex. ma fonction saxpy fait partie d'une bibliothèque (qu'on pourrait appeler "blas" pour fixer les idées..), eh bien à ce moment que peut faire le compilateur ? gerer tous les cas ? (x bien aligné , mais pas y, x et y bien alignes, etc). Je crois que c'est ce que fait la lib http://math-atlas.sourceforge.net/ , mais ça me semble difficilement envisageable pour un compilateur sinon bonjour le bloat.

Et comment est-ce que ça gere les histoires d'alignement ? pour que SSE, Altivec et cie soient efficaces il faut que les données soient correctement alignées en mémoire (sur un multiple de 16 bytes), comment fait -il quand il ne voit qu'un "float*" ou un "double*", par exemple pour vectoriser ce genre de fonction:

void saxpy(float a, float * restrict x, float *restrict y, int n) {
for (int i=0; i < n; ++i) y[i] += a*x[i];
}

?

l'utf8 §a pue

en même temps le cpu qui sera dans les MID d'intel est annoncé entre 0.6 et 2.5W, rien à voir donc avec le pIII qui est dans l'eee, et on peut dire que via a du souci a se faire.

Ainsi les webmasters aurait une visibilité du désagrément que représente l'utilisation de flash pour leurs utilisateurs.

c'est sûr que ça va avoir de l'effet sur youtube ou deezer.. Faut arrêter les combats d'arrière garde, flash s'est imposé pour de bonnes raisons et il a gagné la bataille. Alors au lieu d'essayer de convaincre les gens que ça ne sert à rien, ça serait mieux de mettre les bouchées doubles pour avoir un clone libre !

et d'avoir des filtres un peu plus "fins" que celui là qui était vraiment d'une connerie totale, comme si aucun mail légitime ne pouvait avoir une ligne commençant par "price: xx euros" . J'ai perdu *beaucoup* de temps et d'energie à cause de ce filtre débile.

ah j'ai raté mon lien, c'était https://linuxfr.org//comments/809598,1.html (qui ne parle pas du filtre desactivable mais d'un autre filtre. ovh semble avoir modifié sa regex depuis)

> Les enfants de CM2 sont ils assez mature pour comprendre l'horreur que cela represente?

Il faut arrêter d'infantiliser les enfants, comme aime à le rappeller la si pertinente directrice de cabinet du président.

> - ne supprimant aucun mails (c'est selectionnable dans la config)

ça ne les empeche pas de suprimer malgré tout certains mails ( https://linuxfr.org//comments/809598.html ) quelle que soit ta config.

> Mercurial est pour ce qu'en sait une copie de GIT en python

Pas du tout ! git est une copie de mercurial en C

arf quel boulet /o\
c'était http://gcc.gnu.org/ml/gcc/2000-01/msg00572.html

et alors ? c'est une décision politique qui concerne la fsf et le steering committee. Et ça n'empeche pas rms de poster de temps en temps sur la ml.

> Il faudra te trouver une autre tête de turc.

Pourquoi tete de turc ? est-ce que je l'ai insulté , est-ce que j'ai insinué que sa décision était mauvaise ? arrete tes procès d'intention stp.

bon voilà je me suis fait chier a aller deterrer ce mail où il explique sa position:
http://gcc.gnu.org/ml/gcc-patches/2001-10/msg01040.html

developpe un peu alors, pour l'édification des masses.

llvm n'est pas un projet apple, c'est un projet d'origine académique qui a beaucoup interessé apple (qui a du coup embauché chris lattner, qui etait à l'origine du projet)

Il est bien membre du steering committee http://gcc.gnu.org/steering.html , non ? Donc j'imagine qu'il est très bien placé pour connaitre l'opinion de rms..

Qu'il prefere du bsd n'a rien a voir avec la choucroute. La question est de savoir si oui ou non c'est stallman qui refuse que gcc soit extensible via un systeme de plugins.