freem a écrit 4965 commentaires

ça leur évitera de se contredire plus tard.

Référence à un certain codec? :D

Si je résume, faut prier le dieu Google?

Y'a des chances… mais rassures-toi en te rappelant les préceptes des prophètes Larry Page et Sergey Brin: "Don't be evil".

openMP n'est pas une api C. Ce sont des directives de compilation pour générer du code multithread.

Et on peut pas faire la même chose avec OCaml? (pour la confusion: l'encart rapide sur wikipedia UK dit "Written in C, C++, Fortran" et "Type API" mais je te crois sur parole: n'ayant jamais utilisé et ayant déjà relevé des erreurs ou imprécisions sur wikipedia, je préfère faire confiance à quelqu'un tant que ses propos sont pas aberrants :) )

Il y a eu des études portant sur la productivité (cocomo) quelque soit le langage,

J'ai entendu parle de cocomo… quand j'ai parlé du problème du sucre syntaxique plus important des langages objet genre C++ (public/protected/private sur une ligne propre, accolades souvent seuls sur leurs lignes, déclarations/définitions dans des fichiers distincts -donc 2 lignes de code par prototype-, …) il m'a répondu que c'était plutôt utilisé par les commerciaux et a clairement remis en cause l'intérêt. J'ai gardé le nom dans un coin de mémoire morte mais sans creuser plus du coups.
Si tu as des ressources intéressantes à ce sujet je suis preneur, si tu estimes que ça permets vraiment d'estimer les coûts d'un projet en fonction des langages utilisés.

Tu penses que c'est un démon de quel dieu? Tzeentch ou Khorne ?
Il fallait bien que quelqu'un lui donne l'occasion de se manifester une seconde fois sur ce fil :)

Surtout que bon, il a raison, et que je fais généralement aussi la guerre à cette généralisation…

Les codes c++ et C utilisent massivement openMP qui n'existe pas dans le monde ocaml.

Je connais assez mal openMP, mais qu'est-ce qui empêche OCaml de l'utiliser? Pas moyen d'utiliser une API C dans OCaml? Mais alors, comment faire pour utiliser l'API de l'OS sous-jacent?

Désolé, mais je trouve cet argument plutôt contre que pour OCaml. Même Java et C# savent exploiter une API C… Ce serait dû au fait de ne pas être impératif?

Non, c'est juste l'affichage de ce graph, il est intéressant car la case la plus intéressante est en bas à droite : compact et rapide.

From more-concise at page left to less-concise at the right, from slower at page top to faster at the bottom.

Les langages les plus rapides et concis sont en bas à gauche, non? J'ai toujours du mal avec droite et gauche en anglais…

Au contraire, cela évite de parler de la définition de la "ligne de code". La compression limite l'augmentation de taille des langage verbeux par rapport à ceux abusant des symboles.

Argument intéressant.
Mais je voulais surtout dire que je ne considère pas la taille d'un code comme un indice par rapport au fait qu'il soit lisible: perl produit des codes pouvant parser des documents complexes en peu de lignes, mais il est tout bonnement horrible à lire… A contrario, java est très simple à lire, mais j'ai l'impression qu'il se transforme souvent en romans à l'eau de rose, et mieux vaut avoir 2 écrans larges pour coder confortablement.

Mais les problèmes de logiciels dans ce domaine,

De quel domaine parles-tu? Dans la discussion, on parlait de façon assez générale il me semble… cette série de bench est intéressante, je suis d'accord, je rappelais juste (pour la même raison que je parlais de mauvaise foi en défendant le C++ sur tous les points) que les bench sont toujours là pour montrer l'efficacité dans un domaine précis.
Ici, ça semble être le calcul scientifique?

Attends… t'es en train de dire qu'un langage générant du C était plus rapide que le C?

Tu cherches à me faire bugger par une boucle infinie ou quoi? XD

Un médiateur?

Toutes les filiales de la FSF du monde n'auront aucun poids sur le choix du W3C… les seuls qui peuvent faire quelque chose seront les éditeurs d'un des 3 navigateurs de tête.
Je doute très franchement que Mozilla parvienne dans le cas ou ils le souhaitent bien sûr, à convaincre le W3C face aux intérêts économiques.

A part des lois dans assez de pays, je doute que ce soit possible en fait. Et les lois ne seront jamais dans la direction d'accorder plus de libertés (en considérant que freiner les DRM améliore la liberté, bien entendu) aux citoyens, c'est pas trop à la mode en ce moment… les majors ont plus de chances d'y arriver: eux ont les sous.

J'ai aussi failli le relever tellement c'est gros: sur les 17 organismes, 4 ou 5 (juste le tiers quoi) sont la FSF :D
4 ou 5 sont des partis pirates de divers pays…

Je doute fort que cette lettre impacte, mais tant mieux si c'est le cas.

Exact. Pardon.

Lisaac battait le code C

Battait, ça veut dire que C a rattrapé Lisaac ensuite?

Et sinon, le C++ n'a pas ces problèmes il me semble, et pourtant les bench disent souvent la même chose: il est souvent plus lent que le C.

J'ai aussi vu ce bench, je crois :)
C'était un moment d'anthologie pour moi qui aime rire.

C'est marrant de dire qu'un langage mort est capable de faire mieux que les existants… pourtant, il y a pas mal de langages de niche (dans la catégorie merdique, j'appelle PowerBuilder!), donc je suis intrigué qu'il n'ait pas réussi s'il est meilleur (bien que ce soit très possible, je ne le nie pas).

Lisaac a été premier de ce benchmark

Ce benchmark est à 2 dimensions: taille du code (et pas expressivité) à l'horizontale et vitesse d'exécution sur la hauteur, si je ne me trompe pas?
Pour le coup (prêcher pour ma paroisse avec force mauvaise foi - comme ça c'est dit ;) - ne m'a jamais empêché de dormir) je remarque que comparer ocaml au C++ est intéressant en effet j'ai regardé sur du quad-core (C++ et les thread c'était pas ça, jusqu'au C++ après tout… toujours pas testé d'ailleurs) et je remarque qu'Ocaml est plus économe en mémoire. Sur 3 domaines. Equivalent sur 2, et il perds sur 5.

Niveau vitesse, il atteint C++ sur 2 domaines, les autres C++ gagne.
Code plus petit (de moitié) dans 1 cas, plus grand dans 2 cas, et équivalent dans les autres.

Pour le coup, je te remercie, ce bench est très intéressant, même si je m'en suis un peu servi pour embêter le monde mesquinement :)

Notes un peu plus objectives et de moins mauvaise foi:

• dans la config ou OCaml se place le mieux, c'est à dire x86 un seul coeur, il se fait moins démonter… Problème de compilateur en retard dans les autres domaines?
• je n'ai pas utilisé les graphiques pour comparer, ni les chiffres brut, mais la section " 2 : Are the OCaml programs faster? Approximately.". C'est celle qui m'arrange le plus après tout ;)
• je n'ai pas pu regarder la comparaison avec "shortest C++", je sais pas pourquoi. Dommage, ça m'aurait pas mal intéressé… rien que comparer shortest C++ avec G++C++ pour voir à quel point l'optimisation est utile aurait été sympa
• il n'y a que des algo de calcul, donc pas d'accès aux ressources, de gestion d'IHM, et caetera. Donc, comme d'hab avec les bench, résultats à n'utiliser que pour des optimisations des "zones de calcul".
• ils mesurent la taille du code en octets, en ayant enlevé commentaires et espaces, et en compressant le texte ainsi obtenu. Franchement… je trouve difficile de trouver une façon moins pertinente de mesurer la taille des codes.

En même temps, la souris, c'est juste le périphérique de pointage le plus connu, et qui a engendré les IHM graphiques telles qu'on les connaissait jusqu'a il y a peu…

Mouai, enfin, on touche quand même là à quelque chose de bien plus important qu'un nouvel OS… on parle du net en général!

Je n'arrive a rien trouver d'autre que les articles wikipedia sur lisaac… le site officiel n'affiche qu'une page avec sa propre URL en titre centré gris, le wiki à l'air HS, et les seuls trucs que je trouve à son sujet sont les endroits ou l'on peut utiliser son source… pas envie de fouiller dans du code source inconnu la :)
As-tu d'autres infos?

Pour OCaml… les seules choses que je lise sur wikipedia au sujet de sa vitesse, c'est que ça dépasse les 50% de la vitesse du C, et le passage ou il est dit que ses fonctions sont plus rapides que celles des langages impératifs contiens le mot théoriquement. Je sais qu'on ne peut pas forcément prouver (benchmark? Y'a toujours quelqu'un pour les renier…) qu'un langage est plus rapide qu'un autre, mais je me demande de quel top 10 tu parles?

En tout cas +1 pour avoir parlé de lisaac, il semble intéressant.

Ça fait quelques années que j'ai tendance à utiliser systématiquement des langages de haut niveau, et quand je vois des trucs comme ça,

Allez, j'ai envie de tomber dans ton troll:

Ca tombe bien, C++ est un langage de haut niveau. Il est aussi bas niveau, cependant. Donc moyen niveau selon wikipedia, parce qu'il intègre des éléments des 2.
Note quand même que, perso, je me passe très bien de l'allocation mémoire, y compris pour les collections polymorphes, grâces à boost::ptr_container.

C++

C++ (pronounced "see plus plus") is a statically typed, free-form, multi-paradigm, compiled, general-purpose programming language. It is regarded as an intermediate-level language, as it comprises both high-level and low-level language features.

quand je vois des trucs comme ça

Le truc que tu vois qui ne te donne pas envie, ça s'appelle le paradigme de la programmation générique et selon wikipedia, "C'est un concept important pour un langage de haut niveau car il permet d'augmenter le niveau d'abstraction du langage."

Faut pas confondre langage de haut niveau et langage simpliste :D

plus imbittable que le code C++: les erreurs retournées par le compilateur, avec un petit bonus quand la STL est impliquée et qu'il faut scroller dans le terminal pour retrouver le début de la dernière erreur…

Enfin un peu de vérité… un poil obsolète, mais malgré tout encore d'actualité. Essaies clang.

Pour clôturer ce message, le problème du C++ c'est pas le langage lui-même, mais la pauvreté de sa lib standard, qui a grandement été fixé par C++11 et devrait être encore largement amélioré dans 2-3 ans. En attendant, y'a boost.
Et pour les IHM, t'as le choix: MFC, Qt, GTK, WxWidgets…

Ou alors son échelle à un putain de palier nécessitant du matériel d'escalade ;)

Je pense qu'on arrive au stade de la fusée la :)

Mea culpa, j'aurais du vérifier l'assertion de "2011" faite avant moi :/

Bref, on verra. 😊

On verra dans au moins 4 ans, au minimum. 2 ans mini pour atteindre la prochaine stable, et mini 2 nouvelles années pour que la prochaine stable devienne old-stable.

A part ce point important, je pense que ça va durer longtemps la maintenance de sysvinit chez Debian (et gentoo pour le peu que j'en connais… je vais rester sur Debian, mais je pense que plusieurs des points suivants concernent aussi gentoo):

• c'est une distribution qui s'adresse à des gens qui aiment bidouiller eux-même ET qui visent la liberté et le choix. J'inclus la liberté par rapport aux licences, mais aussi par rapport aux tendances générales: les utilisateurs utilisant LILO ou n'ayant pas de DE ne sont pas rares sur la ml internationale.
• kFreeBSD est encore un peu jeune, mais j'ai bien l'impression qu'il attire pas mal de monde. Peut-être que cette impression est biaisée par le fait que moi-même, je me sens attiré…
• dans 4 ans, si systemd continue de rajouter des palanquées d'options, il sera devenu un bloatware. Pour Debian, se baser sur un bloatware ne sera pas acceptable: la distro qui se veut l'OS universel doit pouvoir marcher sur de vieilles machines.
• si ce n'est pas le cas, le travail de maintenance parallèle ne sera pas si gros que ça, surtout si des outils sont faits pour générer les script à partir des fichiers de systemd.
• c'est fou le nombre de gens qui n'apprécient pas les trucKit et dbus, l'air de rien.

Le très jeune projet « Debian GNU/kFreeBSD » (sorti avec Debian Squeeze, en février 2011) justifiera-t-il de rejeter systemd comme solution par défaut ? Ce choix impliquerait, pour les contributeurs Debian, une plus grande quantité de travail : il faudrait en effet maintenir SysVinit/initscripts.

Non. Même s'il n'est pas par défaut, la quantité de travail sera la même: déjà, pour les versions 6 et 7 de Debian qui seront encore maintenues, et ensuite parce que par défaut ou pas, les paquets sont maintenus. KDE, LXDE et XFCE ne sont pas les options par défaut, pas plus qu'i3, et ils sont bien maintenus…
La mise par défaut n'augmentera donc pas la charge de travail.

C++11 à justement intégré des outils qui permettent de simplifier les messages d'erreur: les assertions statiques

Sinon, je ne crois pas que le C++ ait un jour été destiné à être un langage de programmation pour débutant.
Pas plus que les design pattern ne doivent être employés sans réflexion (surtout pas même, ça te pourris un code très vite sinon), donc la réflexion qu'engage cet article me semble plutôt salutaire.
De là à qualifier les sources affichées de "template de haut vol" par contre, il y a un gouffre que je n'oserais pas franchir. Si toi oui, alors ne lis jamais le source de la STL fournie avec Gnu… (ça m'arrive régulièrement, mais je suis toujours largué quand je le fais)

J'avais un doute sur le fait qu'il était ironique ou pas… me suis fait tromper par le coup du code natif, et il me semblait bien avoir lu il y a longtemps qu'il était possible de le faire (même si c'est… bref, c'était aussi y'a 6ans).

C'est le matin :)

Tu codes tassé toi dis donc, ça coûte si cher que ça les lignes vides? :D

Sinon, autre version, avec une méthode supplémentaire à implémenter:

void visitBinaryExpression(BinaryExpression& expr) {
  Type *left = expr.getLHS()->MethodeSup(*this);
  Type *right = expr.getRHS()->MethodeSup(*this);
  Type *result = ComputeType(left, right);
  setResult(result);
}

class Type
{
  virtual accept(fooBar*)=0;
  Type* MethodeSup(FooBar* foo)
  {
    accept(*foo);
    return getResult();
  }
};

Pour le coup, la lisibilité de visitBinaryExpression est la même, il n'y qu'une seule méthode supplémentaire a créer.

Note que je suis pas sûr de la bonne équivalence du code, vu que ton getResult() ne semble lié à aucun objet. J'ai donc supposé un prototype genre "Type* TypeDerive::getResult(void)" mais ça reste une supposition.
Si c'est lié à autre chose, le même principe peut se faire aussi de toute façon.

Je pense aussi que tu vas lever l'argument de la méthode virtuelle pure qui empêche d'utiliser accept() sur Type, mais ce n'est pas parce qu'une méthode est virtuelle pure qu'il est interdit de l'implémenter. C'est juste les filles ont l'obligation de le faire (j'ai appris ça il y a quelques mois, j'ai testé vite fait et effectivement… mais je n'ai pas trop joué avec, pas eu l'utilité encore).

PS: j'ai l'impression d'avoir merdé quelque part… alors je m'excuse par avance -.-'

Mis à part ça tout le monde sait que Java gère l'héritage multiple, que l'héritage privé est possible, que les annotations de type sont préservées à l'exécution et que la plupart des compilateurs Java produisent du code natif…

Pas moi.
Je veux bien des sources d'ailleurs pour compléter ces lacunes?

S'il s'avère que c'est effectivement le cas, je risque de n'avoir plus que les unsigned à opposer :D (euhh… y'a pas encore, dis?)

roi c'est pas plutôt Retour sur Investissement ? (Return On Investment)

Dans un programme qui manipule des images, c'est moyennement crédible :) mais bon, c'est pas du code dont je suis fier… ça marche, c'est sûr, mais bon…

Je suppose que je mettrais justement le if/else dans une autre fonction, avec un nom qui indique ce que fait cette condition. myIntVectorIterator est un nom très long, est-ce qu'il n'y en a pas un plus court qui ait un sens dans le contexte actuel ?…

D'un autre côté, si tu as une boucle sur un ensemble de données appartenant à un conteneur (allez, un vector, soyons fous) ou tu n'effectue une action que dans un cas, il y a les algo du C++ (et j'oublie volontairement pour le moment le C++11 qui a introduit range_loop et lambda):

• for_each
• transform
• find_if
• …

Sachant que le reproche le plus populaire fait au C++ est la petite taille et le manque de fonctionnalités de la lib standard, j'imagine que les autres langages n'ont pas cette lacune?

for(myIntVectorIterator = myIntVector.begin(); myIntVectorIterator != myIntVector.end(); myIntVectorIterator++) if (*myIntVectorIterator % 2) {
    cout<<*myIntVectorIterator<<" ";
    //Should output 1 3 5
}

void print(int i)
{
  if(i%2)
    std::cout<<i<<" ";
}
...
...
...
  for_each(myIntVector.begin();myIntVector.end();print);

Je sais que cette ancienne méthode n'était pas appréciée (code déporté ailleurs, et syntaxe pénible quand on veut plus d'arguments due à l'emploi de foncteurs, entres autres) mais je trouve que ça réduit l'illisibilité de certaines (plus de la moitié des boucles for je pense) boucles de façon assez propre.
Pas les boucles for ou l'on incrémente plus d'un pointeur (toujours trouvé ça dégueu perso), ni les boucles où l'intervalle n'est pas connu avant l'exécution du corps, ni celle ou le pas n'est pas uniforme, par contre.
Donc, dès qu'on utilise un truc genre "exit" ou "return" au milieu de la boucle, des modifications du compteur/itérateur, ça n'aide plus.

Maintenant, si je prend Java, ou un C++ plus moderne (allez, va pour C++, moins de risque de me lourder):

for(auto i: myIntVector)
{
  if(i%2)
    std::cout<<i<<" "; 
}

Je pense qu'il n'y a nul besoin de commenter de tels codes (pourtant j'ai même viré le type de i, chose que je ne fais pas trop)…

(oui, je sais que je vais dans ton sens, mais pour moi on peut très bien se passer de commentaires explicites et avoir un code documenté. Même si parfois les commentaires aident.)

J'ai compris l'article, même si je suis assez septique sur les raisons d'utiliser la version template… mais un des commentaires plus haut à répondu avec un assez pertinent: ABI break restreinte (faudra que je réfléchisse un peu au comment du pourquoi, par contre, je n'ai pas encore pris le temps de penser en détail).

Par contre, il y a des "avantages" de la version template sur lesquels je suis vraiment dubitatif et ou j'aimerai une explication:

Autre avantage, si on ajoute une classe dans la hiérarchie et qu'on n'a pas mis de méthode par défaut, on tombera dans le cas de Base. Ce cas ne sera sans doute pas pertinent, mais ça compilera. Avec le Visiteur polymorphe, il faudra ajouter la méthode adéquate dans le visiteur sinon, ça ne compilera pas.

Justement, je trouve plutôt utile que le compilateur refuse de compiler quand le cas n'est pas pertinent, ça évite les bogues…

Mais on peut faire mieux et mettre le type de retour dans le template du visiteur.

Je ne vois vraiment pas l'intérêt? Quand j'ai eu besoin de visiteur, c'était pour effectuer un traitement sur les données (sur un arbre dans mon cas passé). Je ne parviens pas à voir de situation ou je voudrais récupérer une donnée sur l'acte de visiter, sachant que le type de donnée en question va varier en fonction de l'objet visité… enfin, je m'embrouille, mais bref, j'aimerai un exemple concret de l'intérêt de ce point?

Autre petit plus inspiré de LLVM et qui là, peut tout à fait s'appliquer au Visiteur polymorphe.

Pas vraiment un plus, puisque tu le dis toi-même, ça s'applique aussi à la version polymorphe?

Si je résume, on aurai la version template qui permet d'éviter d'avoir à utiliser la RTTI et de casser l'ABI, et la version polymorphe qui elle offre de meilleures performances?