Bon, j'ai vaguement essayé de ne rien dire concernant le troll BSD Vs GPL, de savoir à qui avait la plus grosse [1]. Mais, puisque tu te fiches de dire de la merde, je t'avoue que tes arguments, où tu dis que tu te fiches de savoir si ce que tu racontes est vrai, me semblent tout à coup bien moins intéressants à lire. Que tu sois exaspéré par les commentaires de certains, et que tu répondes en conséquence, admettons ; que, pour prouver que tu as raison, tu te permettes de mentir, c'est autrement plus gênant.
« Certaines versions de BSD ne sont pas compatibles avec la GPL »
Tu es sûr de toi ? À ma connaissance, mis à part la clause de publicité (donner le nom des codeurs), je ne connais pas de licence BSD impliquant de garder le logiciel sous BSD.
« Bof les x86 (ainsi que d'autre proc) sont capable de reordonnancer les instructions. Or le volatile n'est utile que pour le compilo. Donc sans "memory barrier" y a des chances que ca marche pas. »
Euh, pas que pour le compilateur. Ça te garantit un comportement à l'exécution, et l'Out-of-Order n'y changera rien. Mais c'est vrai que si tu n'as pas de cohérence de cache, l'utilisation de volatile n'est pas bien intéressante.
« hum et tu fait comment pour modifier ton entier de maniere atomique (sans que plusieurs process quitte la boucle en meme temps) ? »
En fait je ne vois pas trop où est le problème de threads quittant la boucle en même temps, étant donné que c'est ce qu'on veut. Plus exactement : si j'ai X threads à synchroniser, et que chacun a un boulot prenant grosso-modo le même nombre de cycles, alors je peux tenter une attente active pour réduire au maximum le temps de synchro. Ensuite, je n'ai plus qu'à avoir un pseudo code du genre
volatile int n = NB_THREADS_TOTAL;
/* début du thread : « fork » */
/* boulot ... */
n--; /* s'effectue atomiquement, sans risque de cafouillage car c'est un volatile int (on suppose un mécanisme de cohérence de cache) */
while (n > 0);
/* join(), ou bien suite du boulot à faire pour le thread */
En pratique, quand les messieurs d'OpenBSD ont gueulé un grand coup contre tous ces profiteurs qui utilisaient OpenSSL/OpenSSH sans jamais rien reverser (argent ou matériel), certaines boites qui font leur beurre en partie avec ont fini par donner un petit quelque chose. Comme quoi, si le projet en vaut le coup, licence BSD ou pas, les boites veulent bien aider aussi (évidemment, il faut que ce soit dans leur intérêt).
On peut se permettre ça car en pratique, tu n'aura pas d'état inconsistant d'un registre entier (tous les bits sont basculés en même temps). Par contre, ça a un inconvénient si tu t'es planté pour l'attente, notamment pour le multi-coeur : un coeur se retrouve à monopoliser le bus d'accès mémoire, et peut donc empêcher ses petits camarades de travailler (donc il ne faut pas se planter).
[1] en fait il faut raffiner un chouilla plus, mais c'est l'idée.
« Ce qui est arrivé à Con, est arrivé à d'autres et aussi dans le domaine des serveurs. Vmware a essuié un refus il y a peu. IBM a aussi pris un refus pour son modèle de thread. Etc. »
Je ne sais pas si tu as lu l'article original, mais CK dit que son scheduler, qui pourtant avait été critiqué, a ensuite été adopté comme modèle, et récrit from scratch par d'autres dévs du noyau (ceux qui justement critiquaient son approche). C'est ça qui l'a fait craquer, plus que le refus en lui-même : le côté « non, on veut pas de ton truc car on pense que le concept ne convient pas, mais finalement l'idée est bonne, on va le refaire à notre sauce ».
Tu parles d'IBM, mais leur modèle de threads était plus flexible et performant que celui actuellement utilisé. Sauf que bon, comme le scheduler codé par un pote du mec qui a fait les NPTL, ben... Ils se sont arrangés pour que ça colle bien l'un avec l'autre (rendant l'un dépendant de l'autre, en fait), ce qui a nécessairement désavantagé les threads d'IBM...
« Bref, je suis 100% d'accord avec toi sur le fait qu'un client lourd est mieux coté perfs, mais pas la peine de donner des argument foireux contre les applis web... »
Pas seulement côté perfs. Gmail par exemple est plutôt bien foutu ergonomiquement parlant ; n'empêche, le temps de latence pour aller d'un mail à l'autre est insupportable si tu t'en sers de « client » principal. Franchement, si toutes les applications web étaient faites façon gmail & co, ce serait vraiment un grand pas en avant, mais c'est vraiment beaucoup, beaucoup moins bien qu'un client natif.
Tout ceci sans parler du fait que pour le moment, c'est (X)HTML+javascript, et que javascript c'est sympa quand tu veux faire quelques petits trucs, mais quand tu développes de GROS trucs, c'est un langage extrêmement difficile à debugger, comparé aux autres.
Dans le principe, si le langage pouvait inclure la notion de parallélisme ce serait évidemment mieux.
Après tout dépend du but. Dans le cas de « bêtes » sections parallèles, avec un modèle à la fork/join (comme pour OpenMP), du moment que cette section prend du temps et nécessite réellement du calcul avec des dépendances « lourdes » (qui nécessitent de la synchronisation), alors oui, pourquoi pas.
Mais dans le cas où tu peux t'arranger pour qu'il n'y ai pas de synchro ou presque (par exemple parce que tu peux évaluer - statiquement ou au lancement du programme - le nombre d'opérations qui vont être effectuées, à 0,1% près), et qu'en plus, tu dois absolument aller vite, il ne te reste plus que des langages type C, ou FORTRAN (OCAML me vient aussi à l'esprit, mais je n'ai pas l'impression qu'il y ait de vraies constructions pour le parallélisme dans le langage), car malheureusement, dans la plupart des papiers parlant de parallélisme que j'ai pu voir (et c'est aussi vrai pour les implémentations classiques d'OpenMP), il y a toujours des synchro lourdes dans le cas de déclarations plus ou moins explicites de sections parallèles.
Du coup, il va falloir que je teste un chouilla TBB, mais je pense que ça ne s'interfacera pas trop avec MPC ... :-)
« Tout est normal, l'OS est là pour utiliser au mieux les ressources. Si deux thread sont attachés à un même cpu »
Non. Je te donne le cas d'un processus unique qui pouvait aléatoirement être migré entre un coeur et l'autre. Il y a quelques générations du noyau de cela, c'était même un ping pong permanent (et très coûteux). Depuis l'ordonnanceur a moins la bougeote, mais il lui arrive encore de migrer un thread/processus d'un processeur à l'autre même lorsque ce n'est pas judicieux.
Depuis Bull a pondu les CPU sets, qui permet de dire exactement sur quel processeur virtuel (thread, coeur, processeur) tu veux « visser » un processus ou un thread (la différence entre les deux étant relativement minime, vu que dans tous les cas on appelle clone()).
Je m'en sers en ce moment pour faire tout un tas de tests et autres benchmarks (notamment, évaluer l'impact des caches partagés par rapport à du SMP classique), et je pense que pour une application mono-utilisateur, on finira par devoir un minimum s'y intéresser, ne serait-ce que pour certaines tâches critiques. C'est un peu ce que fait Mac OS quand de l'OpenGL est exécuté : plutôt que d'avoir un processus affecté à un coeur par le système, et le runtime OpenGL qui s'exécute sur ce même coeur, on le fait se lancer sur l'autre coeur, pour alléger la charge. OpenGL n'en est pas rendu thread-safe pour autant, mais on a au moins découplé le côté « rendu » du côté « traitement ».
« Il y a changement de contexte s'il n'y a pas assez de cpu (le cpu est alors affecté à un autre thread qui en a besoin). On est dans le cas où il n'y a moins de cpu que de threads actifs/éligibles et au-lieu de laisser un cpu en attende d'un lock, on l'affecte à un autre thread. »
Je suis un peu sceptique. J'ai déjà eu le cas d'un processus (pas d'un thread, nous sommes bien d'accord) qui était migré d'un coeur à un autre, sans autre raison que l'ordonnanceur l'avait décidé (tu comprends, un coeur travaillait à 100%, pas l'autre, alors forcément, l'ordonnanceur a voulu donner du boulot à ce dernier ...). Du coup je me demande si ce genre de comportement ne peut pas se reproduire -- mais bien évidemment, c'est plus ou moins indépendant du fait qu'on manipule un mutex ou non.
« *BSD a beaucoup de programme sous GPL. T'as des exemples de programme qui ont été contaminés par la GPL ? »
Si tu parles des systèmes d'exploitation BSD, tu as raison, ils embarquent aussi des softs sous GPL (GCC n'étant pas des moindres). Maintenant, c'est clairement plus parce qu'ils n'ont pas de main d'oeuvre pour faire leurs propres outils sous BSD.
make, par exemple, est fournie version BSD sur les systèmes, et est bien différenciée de gmake (qu'il faut explicitement installer).
« Je suis sûr que "message passing" doit utiliser un lock ou un semaphore. »
C'est vrai, mais c'est laissé au soin de l'implémentation d'une part, et souvent ça utilise les mécanismes matériels mis à disposition d'autre part. Sachant que le passage de message peut se faire en synchrone ou asynchrone.
« En passant, un mutex (ou section critique sous Windows) ça ne bouffe rien si le nombre de thread actif est inférieur ou égal au nombre de cpu/core. »
Euh, tu es sûr de ton coup là ?
De ce que j'avais compris, l'utilisation de mutex te soumet potentiellement à un changement de contexte, quel que soit le nombre de processeurs actif. Je peux me tromper bien sûr.
De plus, dans un contexte plus restreint (le calcul haute performance, où les entrées/sorties sont rares), synchroniser comme un malade est souvent synonyme de mauvaises performances.
« Sont un peu maso quand meme pour openmp. autant partir sur du c et du pthread, parce que openmp je trouve ca assez porc, définir des macros etc... »
Sauf que la notion de thread en FORTRAN, ben ... Elle n'existe pas. D'où le besoin de machins genre OpenMP pour rajouter du parallélisme explicite à un langage qui ne connaît pas ça officiellement.
De plus, en utilisant les pragma en C ou les commentaires correspondants en FORTRAN, tu permets au compilateur de faire tout plein d'analyses en statique (pour peu que le compilateur sache en tirer parti, ce qui n'est pas du tout évident).
« Multicoeur c'est du multi-cpu. Au niveau appli/programmation on ne voit pas la différence. »
Ça dépend du type d'application. Lorsque deux coeurs partagent le même cache, la notion de localité des données peut prendre une grande importance. La notion de proximité des processeurs aussi, du coup (je pense par exemple aux stations de travail et serveurs SMP/CMP, genre bi-xeon core 2 duo).
Imagine que tu sois sur une station de travail bi-proc, bi-coeur. Tu es graphiste, et tu utilises une application qui modifie tes jolies images. Bon, certains filtres effectuent plusieurs passes sur tes données. Là, avoir un SMP « pur » ou un SMP/CMP peut te faire gagner 50% dans le cas d'une bonne utilisation de la localité des données, ou au contraire te faire perdre 100% de puissance potentielle.
La fonction m'affiche bien <taille d'une adresse char *>.
Et effectivement, d'après la FAQ de fclc, même si pour déclarer officiellement un tableau multi-dimensionnel en passage de paramètre à une fonction, il faut faire quelque chose du genre
void f(char tab[42][S1][S2]....[Sn]) { ... }
Au final, le compilateur voit bien le tableau comme étant
void f(char (*tab)[S1][S2]...[Sn]) { ... }
Mais par contre déclarer les autres dimensions est nécessaire pour ne pas avoir à simuler toutes les dimensions à la main.
« C'est de la provocation ça. parce que entre (int)truc et static_cast(truc) je préfère de loin le premier surtout quand le int ou truc se voit prefixé avec Mon::Namespace::De::Vingt::Metres::De::Long (ok c'est un peu exagéré). »
Sauf que le cast en C est moche parce que le C est faiblement typé, et que donc (type)truc passe toujours. Et ça, c'est tout à fait inacceptable dans un langage orienté objet, je trouve.
[^] # Re: -asse = affectif
Posté par lasher . En réponse au journal Qui traite du D de Digitalmars, et dans une moindre mesure du français chez les jeunes, ainsi que du vote des personnes ayant double nationalité. Évalué à 3.
Mon Petit Robert 2006 me dit que "Connard, -arde, connasse, conne (conard -> conasse)", ça a du coup bien un masculin et un féminin...
[^] # Re: Alors ca c'est du bon
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 4.
[1] liberté, évidemment.
[^] # Re: Alors ca c'est du bon
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 0.
Tu es sûr de toi ? À ma connaissance, mis à part la clause de publicité (donner le nom des codeurs), je ne connais pas de licence BSD impliquant de garder le logiciel sous BSD.
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 2.
Euh, pas que pour le compilateur. Ça te garantit un comportement à l'exécution, et l'Out-of-Order n'y changera rien. Mais c'est vrai que si tu n'as pas de cohérence de cache, l'utilisation de volatile n'est pas bien intéressante.
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 2.
En fait je ne vois pas trop où est le problème de threads quittant la boucle en même temps, étant donné que c'est ce qu'on veut. Plus exactement : si j'ai X threads à synchroniser, et que chacun a un boulot prenant grosso-modo le même nombre de cycles, alors je peux tenter une attente active pour réduire au maximum le temps de synchro. Ensuite, je n'ai plus qu'à avoir un pseudo code du genre
Évidemment, je ne donne que l'idée principale.
[^] # Re: Et Novell?
Posté par lasher . En réponse au journal Microsoft vous aime.. Évalué à 4.
[^] # Re: Et alors ?
Posté par lasher . En réponse au journal Microsoft vous aime.. Évalué à 7.
En pratique, quand les messieurs d'OpenBSD ont gueulé un grand coup contre tous ces profiteurs qui utilisaient OpenSSL/OpenSSH sans jamais rien reverser (argent ou matériel), certaines boites qui font leur beurre en partie avec ont fini par donner un petit quelque chose. Comme quoi, si le projet en vaut le coup, licence BSD ou pas, les boites veulent bien aider aussi (évidemment, il faut que ce soit dans leur intérêt).
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 3.
« entier » étant déclaré volatile int entier;
On peut se permettre ça car en pratique, tu n'aura pas d'état inconsistant d'un registre entier (tous les bits sont basculés en même temps). Par contre, ça a un inconvénient si tu t'es planté pour l'attente, notamment pour le multi-coeur : un coeur se retrouve à monopoliser le bus d'accès mémoire, et peut donc empêcher ses petits camarades de travailler (donc il ne faut pas se planter).
[1] en fait il faut raffiner un chouilla plus, mais c'est l'idée.
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 2.
Sauf que le T&S ne fonctionne (à ma connaissance) pas pour un grand nombre de processeurs (problèmes liés à la cohérence de cache, etc.).
[^] # Re: Regrettable
Posté par lasher . En réponse au journal L'interview vérité de Con Kolivas. Évalué à 3.
Je ne sais pas si tu as lu l'article original, mais CK dit que son scheduler, qui pourtant avait été critiqué, a ensuite été adopté comme modèle, et récrit from scratch par d'autres dévs du noyau (ceux qui justement critiquaient son approche). C'est ça qui l'a fait craquer, plus que le refus en lui-même : le côté « non, on veut pas de ton truc car on pense que le concept ne convient pas, mais finalement l'idée est bonne, on va le refaire à notre sauce ».
Tu parles d'IBM, mais leur modèle de threads était plus flexible et performant que celui actuellement utilisé. Sauf que bon, comme le scheduler codé par un pote du mec qui a fait les NPTL, ben... Ils se sont arrangés pour que ça colle bien l'un avec l'autre (rendant l'un dépendant de l'autre, en fait), ce qui a nécessairement désavantagé les threads d'IBM...
[^] # Re: avoir un client e-mail qui soit aussi un webmail ?
Posté par lasher . En réponse au journal La fin de Thunderbird ?. Évalué à 6.
Pas seulement côté perfs. Gmail par exemple est plutôt bien foutu ergonomiquement parlant ; n'empêche, le temps de latence pour aller d'un mail à l'autre est insupportable si tu t'en sers de « client » principal. Franchement, si toutes les applications web étaient faites façon gmail & co, ce serait vraiment un grand pas en avant, mais c'est vraiment beaucoup, beaucoup moins bien qu'un client natif.
Tout ceci sans parler du fait que pour le moment, c'est (X)HTML+javascript, et que javascript c'est sympa quand tu veux faire quelques petits trucs, mais quand tu développes de GROS trucs, c'est un langage extrêmement difficile à debugger, comparé aux autres.
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 2.
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 2.
... Et c'est exactement ce que je fais. :-)
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 3.
Après tout dépend du but. Dans le cas de « bêtes » sections parallèles, avec un modèle à la fork/join (comme pour OpenMP), du moment que cette section prend du temps et nécessite réellement du calcul avec des dépendances « lourdes » (qui nécessitent de la synchronisation), alors oui, pourquoi pas.
Mais dans le cas où tu peux t'arranger pour qu'il n'y ai pas de synchro ou presque (par exemple parce que tu peux évaluer - statiquement ou au lancement du programme - le nombre d'opérations qui vont être effectuées, à 0,1% près), et qu'en plus, tu dois absolument aller vite, il ne te reste plus que des langages type C, ou FORTRAN (OCAML me vient aussi à l'esprit, mais je n'ai pas l'impression qu'il y ait de vraies constructions pour le parallélisme dans le langage), car malheureusement, dans la plupart des papiers parlant de parallélisme que j'ai pu voir (et c'est aussi vrai pour les implémentations classiques d'OpenMP), il y a toujours des synchro lourdes dans le cas de déclarations plus ou moins explicites de sections parallèles.
Du coup, il va falloir que je teste un chouilla TBB, mais je pense que ça ne s'interfacera pas trop avec MPC ... :-)
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 3.
Non. Je te donne le cas d'un processus unique qui pouvait aléatoirement être migré entre un coeur et l'autre. Il y a quelques générations du noyau de cela, c'était même un ping pong permanent (et très coûteux). Depuis l'ordonnanceur a moins la bougeote, mais il lui arrive encore de migrer un thread/processus d'un processeur à l'autre même lorsque ce n'est pas judicieux.
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 4.
Je m'en sers en ce moment pour faire tout un tas de tests et autres benchmarks (notamment, évaluer l'impact des caches partagés par rapport à du SMP classique), et je pense que pour une application mono-utilisateur, on finira par devoir un minimum s'y intéresser, ne serait-ce que pour certaines tâches critiques. C'est un peu ce que fait Mac OS quand de l'OpenGL est exécuté : plutôt que d'avoir un processus affecté à un coeur par le système, et le runtime OpenGL qui s'exécute sur ce même coeur, on le fait se lancer sur l'autre coeur, pour alléger la charge. OpenGL n'en est pas rendu thread-safe pour autant, mais on a au moins découplé le côté « rendu » du côté « traitement ».
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 2.
Je suis un peu sceptique. J'ai déjà eu le cas d'un processus (pas d'un thread, nous sommes bien d'accord) qui était migré d'un coeur à un autre, sans autre raison que l'ordonnanceur l'avait décidé (tu comprends, un coeur travaillait à 100%, pas l'autre, alors forcément, l'ordonnanceur a voulu donner du boulot à ce dernier ...). Du coup je me demande si ce genre de comportement ne peut pas se reproduire -- mais bien évidemment, c'est plus ou moins indépendant du fait qu'on manipule un mutex ou non.
[^] # Re: Alors ca c'est du bon
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 3.
Si tu parles des systèmes d'exploitation BSD, tu as raison, ils embarquent aussi des softs sous GPL (GCC n'étant pas des moindres). Maintenant, c'est clairement plus parce qu'ils n'ont pas de main d'oeuvre pour faire leurs propres outils sous BSD.
make, par exemple, est fournie version BSD sur les systèmes, et est bien différenciée de gmake (qu'il faut explicitement installer).
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 2.
C'est vrai, mais c'est laissé au soin de l'implémentation d'une part, et souvent ça utilise les mécanismes matériels mis à disposition d'autre part. Sachant que le passage de message peut se faire en synchrone ou asynchrone.
« En passant, un mutex (ou section critique sous Windows) ça ne bouffe rien si le nombre de thread actif est inférieur ou égal au nombre de cpu/core. »
Euh, tu es sûr de ton coup là ?
De ce que j'avais compris, l'utilisation de mutex te soumet potentiellement à un changement de contexte, quel que soit le nombre de processeurs actif. Je peux me tromper bien sûr.
De plus, dans un contexte plus restreint (le calcul haute performance, où les entrées/sorties sont rares), synchroniser comme un malade est souvent synonyme de mauvaises performances.
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 2.
Sauf que la notion de thread en FORTRAN, ben ... Elle n'existe pas. D'où le besoin de machins genre OpenMP pour rajouter du parallélisme explicite à un langage qui ne connaît pas ça officiellement.
De plus, en utilisant les pragma en C ou les commentaires correspondants en FORTRAN, tu permets au compilateur de faire tout plein d'analyses en statique (pour peu que le compilateur sache en tirer parti, ce qui n'est pas du tout évident).
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 3.
Ça dépend du type d'application. Lorsque deux coeurs partagent le même cache, la notion de localité des données peut prendre une grande importance. La notion de proximité des processeurs aussi, du coup (je pense par exemple aux stations de travail et serveurs SMP/CMP, genre bi-xeon core 2 duo).
Imagine que tu sois sur une station de travail bi-proc, bi-coeur. Tu es graphiste, et tu utilises une application qui modifie tes jolies images. Bon, certains filtres effectuent plusieurs passes sur tes données. Là, avoir un SMP « pur » ou un SMP/CMP peut te faire gagner 50% dans le cas d'une bonne utilisation de la localité des données, ou au contraire te faire perdre 100% de puissance potentielle.
Donc non, SMP != CMP.
# Petite remarque ...
Posté par lasher . En réponse à la dépêche Ouverture du code de CFE, un nouveau frontend C/C++ et sortie de l'infrastructure de compilation LLVM 2.0. Évalué à 4.
[^] # Re: Le C++ peut être simple
Posté par lasher . En réponse au journal Un langage pour les nuls? Le langage D!. Évalué à 2.
Si j'ai :
void f(void) {
____char tab[42];
____printf("sizeof(tab) == %lu\n", sizeof(tab));
}
J'ai bien 42 en retour. Par contre, de cette manière :
void f(char tab[42]) {
____printf("sizeof(tab) == %lu\n", sizeof(tab));
}
La fonction m'affiche bien <taille d'une adresse char *>.
Et effectivement, d'après la FAQ de fclc, même si pour déclarer officiellement un tableau multi-dimensionnel en passage de paramètre à une fonction, il faut faire quelque chose du genre
void f(char tab[42][S1][S2]....[Sn]) { ... }
Au final, le compilateur voit bien le tableau comme étant
void f(char (*tab)[S1][S2]...[Sn]) { ... }
Mais par contre déclarer les autres dimensions est nécessaire pour ne pas avoir à simuler toutes les dimensions à la main.
Enfin, c'est ce que je comprends de ce qui est écrit là :
http://docs.mandragor.org/files/Programming_languages/C/fclc(...)
[^] # Re: Internet sans pub vs logiciels libres
Posté par lasher . En réponse au journal Adblockblockblock : l'anti-anti-anti-pub. Évalué à 1.
[^] # Re: peut etre que...
Posté par lasher . En réponse au journal Un langage pour les nuls? Le langage D!. Évalué à 4.
Sauf que le cast en C est moche parce que le C est faiblement typé, et que donc (type)truc passe toujours. Et ça, c'est tout à fait inacceptable dans un langage orienté objet, je trouve.