rewind a écrit 3416 commentaires

Pour le problème des versions de compilateurs qui n'ont pas encore certaines fonctionnalités de C++11, je pense que je vais gérer ça globalement via une option dans CMake. En gros, une option LIBES_FULL_CXX11 qui indique qu'on utilise un compilateur qui implémente tout C++11 (désactivé par défaut). Et pour les autres (typiquement les cas que tu cites), on trouve des alternatives. Dans une autre lib, j'avais déjà eu ce genre de souci quand j'avais essayé de compiler avec le GCC de mingw64 qui doit être un 4.7 si ma mémoire est bonne.

Non, mais les tuples sont une des fonctionnalités qu'on a gratos dans caml (si je ne me trompe pas) et qu'on n'avait pas dans C++ jusque là.

J'aurais tendance à privilégier une écriture de la forme suivante, exprimant plus lisiblement l'intention

Là, je pense que c'est une question de goût. Personnellement, je trouve la version avec le user-defined literal plus simple et lisible. Tu peux utiliser la fonction Hash qui aura le même effet.

Finalement, dans mes expérimentations avec libes j'ai préféré utiliser de simples entiers saisis manuellement !

C'est possible aussi ;)

D'ailleurs, c'est toi qui a envoyé un pull request, je ne me trompe pas ? Si tu as d'autres remarques à faire à propos du code, que tu as besoin de fonctionnalités, n'hésite pas à demander. Pour l'instant, je développe au fur et à mesure de ce que j'ai besoin et donc, ça change beaucoup (souvent par ajout). Mais si tu as d'autres besoins, ça m'intéresse de les intégrer.

Le type somme et le filtrage existe dans le nouveau c++ ?

Non, mais on a gagné le type std::tuple.

Par souci d'uniformité, il vaux mieux utiliser using dans du code neuf.

C'est vrai, tu as raison. J'utilise typedef par habitude mais je devrais utiliser using que je trouve beaucoup plus clair. Je vais l'ajouter à mon TODO.

on va déjà avoir std::optional, pas trop de révolution à la fois

Et non ! Il a été enlevé au dernier moment et ne sera donc pas dans C++14. Il arrivera sans doute dans C++17. Et c'est bien dommage, ça aurait apporté un outil génial. Il y a dyn_array qui a subit le même sort.

Je préfère mettre un std::move pour être clair pour celui qui lit le code, qu'il n'y ait aucune ambiguïté sur ce que ça va faire.

Pour ma part … hum hum (sourire gêné) … je vais avoir besoin de plus de 5 minutes pour aller lire ces histoires de move.

Pour comprendre l'intérêt des move, un petit exemple suffit :

std::vector<double> func() {
  std::vector<double> vec;

  // mettre ici tout plein d'éléments dans vec

  return vec;
}

Avant, la dernière instruction provoquait une copie (sauf si le compilateur était intelligent, parfois) ce qui était idiot vu que vec, la variable locale à la fonction, va disparaître juste après le return. On copiait donc des données inutilement. Du coup, la sémantique move a été introduite et maintenant on peut dire : return std::move(vec); pour signaler au compilateur qu'on veut faire bouger ce vecteur, pas le copier. En interne, ça va juste déplacer le pointeur sur les données, ça ne va pas copier les données, et du coup, ça optimise vachement ton code.

Donc, oui, il faut définir un constructeur et un opérateur d'affectation par déplacement, de manière à pouvoir bénéficier de cette sémantique. Bon, après, dans plein de cas, on peut faire une copie, ça ne mange pas de pain. Mais quand tu as besoin de ça, pour des grosses structures, c'est vraiment génial.

mais est-ce que vous connaissez Ocaml? J'ai l'impression que beaucoup de choses sont en fait hyper simple en comparaison.

J'ai fait un peu de caml dans ma jeunesse donc je ne sais pas si ça compte. Mais le fait que C++ (et d'autres langages d'ailleurs) introduise des concepts et des constructions orientées fonctionelles, ça le fait se rapprocher de langages purement fonctionnel. Maintenant, les deux restent suffisamment loin l'un de l'autre à mon sens.

Mais la syntaxe est restée très homogène. Regarde la syntaxe lambda de C++, où la complexité de certaines définitions quand on commence à manipuler des functor, on est plus dans le même monde.

Je pense que là, c'est une question d'habitude. Personnellement, par exemple, j'ai jamais compris la syntaxe de Perl, chaque fois que j'ouvre un script Perl, je n'ai aucune foutue idée de ce que ça peut faire. Pourtant, ça n'empêche pas certain de trouver Perl génial et bien foutu. Moi, la syntaxe C++, hormis les lambdas au début, je la trouve très cohérente. Et maintenant, même les lambdas, je les trouve plutôt bien intégrés.

J'ai appris le C++ quand tout ce fratras de C++11 n'existait pas (je crois même pas qu'on osait lever une exception à l'époque) et Python en version 1.5.2 . En quelques heures, je me suis mis à niveau en Python. Pour C++, j'ai l'impression que je vais galérer beaucoup beaucoup plus.

Le développement de Python s'est fait sur plusieurs années de manière assez incrémentale. Avec C++, on est passé de C++03 à C++11 (soit 8 ans de gestation) en une seule fois, donc la marche paraît plus haute mais elle ne l'est pas à mon sens.

Si un jour un tel débat vient sur la place publique, ça finira par un débat entre le bipartisme ou le centrisme, qui est simplement un débat sur la démocratie.

Personnellement, je ne suis ni pour le bipartisme (surtout quand, comme maintenant en France, et depuis longtemps ailleurs, les deux principaux partis sont d'accord sur l'essentiel) ni pour le centrisme (le centrisme, ça n'existe pas en France, ceux qui se revendiquent du centre ont toujours été alliés électoralement et politiquement à la droite, y compris Bayrou le plus à gauche des centristes). Je suis pour le pluralisme des idées et qu'elles puissent toutes être représentées à leur juste valeur, c'est-à-dire proportionnellement aux électeurs qui ont voté pour ces idées, je suis donc pour le vote à la proportionnelle pour toutes les élections, à base de liste paritaire. Ce qui assurerait une juste représentativité des femmes, qui enlèverait l'aspect personnalisant du vote uninominal, et qui permettrait de se concentrer sur des programmes politiques plutôt que sur la couleur des cravates ou les histoires de cul des prétendants au trône de la République. Le vote à la proportionnelle permet de montrer la nuance dans le résultat, ce que ne permet pas le vote uninominal. Et le système de vote actuel permet déjà ça, pas besoin d'aller chercher un truc moisi.

Prenons un exemple : tu as 3 candidats A, B et C. Tu aimes bien A, mais si c'est B, ça te va à peu près, et tu ne veux absolument pas C. Maintenant, si on t'écoute, ton vote serait A:2, B:1, C:-2. Maintenant, mettons qu'avant ton vote, le total soit : A:10, B:12, C:5. Avec ton vote, tu arrives à A:12, B:13, C:3. Donc B gagne. Mais si tu avais voté A:2, B:-1, C:-2, alors le total aurait été A:12, B:11, C:-2. Ton chouchou A arrive en premier et gagne. Du coup, parce que tu as accordé des points à quelqu'un d'autre que ton chouchou, tu le pénalises et tu risques de faire élire ton deuxième choix, ce qui est pour moi paradoxal. Paradoxal parce que tu préfères A à B mais que c'est ton vote qui permet à B de gagner (bien que tu aies placé A avant B). Il n'y a pas ce problème avec la méthode Condorcet par exemple.

Dans le vote de valeur, il n'y a aucun intérêt, si on soutient un candidat, à mettre des notes intermédiaires pour les autres, au risque de les voir passer. Donc, on se retrouve en fait à voter comme maintenant.

C'est le constexpr qui permet cela

Oui, c'est vrai, c'est plutôt le constexpr qui permet ça. Mais même dans ton exemple, tu pourrais avoir des constructeurs constexpr.

donc pas de risque de collision avec un suffixe "h" qui est déjà défini par l'utilisateur.

En fait, dans C++14, il y aura deux suffixes "s" : un pour les secondes et un pour les chaînes. Mais normalement, aucune collision vu que celui pour les secondes s'appliquent à des nombres et celui pour les chaînes s'appliquent… à des chaînes.

Je ne serais pas aussi pessimiste que toi. Certes il y a des évolutions mais, à mon sens, elles vont dans la bonne direction, à savoir écrire des choses puissantes en moins de lignes. Oui, ça crée pas mal de nouvelles syntaxes, mais au final, on s'y habitue assez vite et on les adopte. Les lambdas, au départ, c'est un peu chaud, mais dès qu'on en a écrit soi-même deux ou trois sur des cas assez simples (comme dans un tri avec std::sort), on comprends le truc et on les range dans la catégorie des bons outils à réutiliser.

Après, est-ce qu'il faut les utiliser ? Non évidemment. Les exemples que j'ai pris ici, j'ai vu que ça passait bien et que ça simplifiait les choses, ça permet d'écrire moins de code pour l'utilisateur de la bibliothèque, respectant ainsi l'adage qui dit qu'en C++, écrire une bonne bibliothèque est difficile quand l'utiliser est facile.

L'autre solution avec C++, c'est de se restreindre à un sous-ensemble et d'ignorer le reste. Après, il y a des trucs qui ne coûtent pas grand chose à faire et qui sont utiles pour les autres. Un exemple qui me vient en tête et que j'ai déjà utilisé, c'est d'écrire une méthode begin() et une méthode end() qui renvoient des itérateurs pour des classes qui ressemblent à des conteneurs. Pourquoi ? Parce qu'après, ça permet d'utiliser le range base for (le même que dans Java) sans aucun problème.

J'ai lu avec intérêt ton nouveau message, et en ce qui concerne l'utilisation de std::function et std::bind, j'ai plus l'impression qu'il s'agit d'aides pour simplifier l'écriture de functors.

Tu n'as pas tout à fait tort. Effectivement, ça existe depuis un moment, notamment dans boost, mais maintenant, c'est en standard. Et en plus, ça se couple très bien avec les lambdas, et ça, ça n'existait pas avant. Ça permet de s'éviter du code superflu quand on doit faire une petite fonction et qu'on n'a pas envie de déclarer une fonction à part, ou une classe.

je me demande quelle est la différence entre cela et utiliser une fonction normale

Tout se fait à la compilation plutôt qu'à l'exécution. Ça améliore les performances et ça peut améliorer la lisibilité. Par exemple dans C++14, ils vont introduire les suffixes "h", "min", "s", "ms", "us", "ns" pour créer automatiquement des durées (std::chrono::duration). Ça va permettre d'écrire des choses du genre :

auto total = 1s + 12min + 3h;

Comme quoi les inquiétudes sur le biais en faveur d'Upstart dus à la présence d'employés Canonical n'était pas complètement fondés.

Ou si. Tous les employés Canonical ont voté en bloc pour Upstart, ou du moins pour barrer la route à systemd. Dans quelle autre distrib communautaire s'est-on posé la question d'Upstart à ce point ? Aucune. Et ça, ça vient bien du fait qu'il y ait des employés Canonical dans le ctte.

son commentaire était tout a fait pertinent

Tellement pertinent qu'à l'heure où j'écris, il est à 0. Comme quoi je ne dois pas être le seul à avoir réagi de cette façon.

Ma boutade n'est pas sur le fond mais sur la forme. Tu admettras quand même que Zenitram est un peu culotté de dire qu'il ne lit pas l'article mais après, il va faire 50 commentaires dont celui auquel je réponds. Mais à propos de quoi puisqu'il ne lit pas l'article ? Donc, je fais comme lui, je vais me permettre de critiquer mais je ne vais pas lire ce qu'il écrit. Il ne m'en voudra donc pas. Il aurait pu expliquer ce que tu dis, calmement et ça serait sans doute mieux passé.

Posté par Zenitram

Poubelle. Pas de lecture plus loin.

Quand tu dis qu'il faut être indulgent sur le code, je trouve que tu te dévalorises beaucoup. Tu as le style d'un développeur Java (du coup, tu utilises un sous-ensemble de C++), mais ça fonctionne très bien, le code est très compréhensible.

ça implique quand même de devoir réécrire tout un tas de trucs… chez Go, pour les changements de nom dans la lib standard, ils avaient développés un outil pour faire les modifications automatiquement, on en est loin là !

laisse aux développeurs de Rust le soin de choisir quand ils considèrent que le projet est suffisamment cohérent et propre pour être stabilisé.

On ne peut pas dire que ce n'est pas stabilisé et en même temps qu'il faut l'utiliser. Or, c'est exactement ce qui est dit à la fin :

Il y aura encore sûrement des changements dans la syntaxe — et dès la parution du la version 0.9, il y en a déjà, voir This week in Rust du 11 janvier — mais le langage est très proche de la complétion et il commence à y avoir suffisamment de ressources en ligne pour apprendre. Il n’y a plus d’excuses pour ne pas se mettre au Rust ! ;)

Pour moi, c'est incohérent ! Et je préfèrerais qu'ils disent : «OK, il va y avoir des changements de syntaxe importants, on va attendre d'avoir tout remanié et ensuite, on appellera à des tests et si pendant suffisamment de temps, on n'observe pas de besoin de nouveaux changements de syntaxe, on décrétera que c'est figé.»

Java, C, C++ sont dans la première catégorie. Python est à la limite (parce qu'il y a un processus pour normaliser). Donc, je choisis cette catégorie là. Surtout que donner Visual Basic comme exemple du second, je trouve ça particulièrement croustillant, ça donne vraiment envie !

Bon, si on arrête de rigoler deux secondes, tes catégories n'ont aucune signification, il y a des bons et des mauvais langages dans les deux (sous-entendu, des langages pour faire des choses utiles). Et ce n'est absolument pas la question que je pose. Je m'étonne qu'un langage qui a déjà un historique assez long et qui est plutôt sur la voie de la finalisation soit encore si instable au niveau de sa syntaxe. Si on prend Go par exemple, il a convergé petit à petit et les changements de syntaxe ont été de moins en moins invasifs jusqu'à la version 1. Là, on change un des trucs mis en avant depuis le début !

Si on voulait faire un parallèle, on prendrait plutôt les clichés dans les romans. Par exemple, quand tu prends 90% de la littérature de médiéval fantastique, c'est uniquement du cliché vu et revu. C'est lassant, et c'est ça qui est dénoncé. Maintenant, ça ne veut pas dire qu'un énième titre de médiéval fantastique rempli de clichés ne marchera pas.