rewind a écrit 3425 commentaires

Le cas que tu présentes est complètement farfelu. Et si on prend l'exemple allemand où les élections fédérales sont à la proportionnelles, on ne peut pas dire que ce soit le chaos total que tu décris là bas.

Et, AMHA, le système de vote actuel permet un choix négatif (suivant l'adage "au premier tour on choisi, au second on élimine"), mais n'est juste pas adapté à cela.

Le système de vote actuel n'est pas vraiment ma référence hein. Et je le redis, pour moi, on ne vote pas pour faire des choix négatifs, ça n'a pas de sens.

mais tu ne peux pas avoir de vote à la proportionnel pour un maire

Raté, en France, on vote à la proportionnelle pour désigner le maire, avec une prime majoritaire certes mais c'est quand même la proportionnelle, ce n'est pas un vote uninominal.

On peut avoir un avis représentatif de celui de la population globale, sans obliger à faire voter tout le monde. C'est de tirer au sort des représentants.

Le tirage au sort, qui semble avoir le vent en poupe, est pour moi l'antithèse de la démocratie. Le vote permet de faire un choix réfléchi sur des options politiques différentes. Tirer au sort, c'est nier ce choix et s'en remettre au sort pour désigner ceux qui appliqueront une politique elle aussi aléatoire. Sans parler du fait qu'il est possible de tirer au sort uniquement des fascistes qui n'appliqueraient pas exactement la politique souhaitée par la majorité (Murphy, si tu nous entends). Je ne comprends même pas qu'on puisse défendre le principe du tirage au sort pour désigner des gens pour nous gouverner. C'est la fin de tout débat d'idée : pourquoi débattre puisque de toute façon, c'est le tirage au sort qui réglera l'affaire ? Non, vraiment, ça ne donne pas envie.

réduire le clientélisme, réduire le bipartisme en supprimant la notion de vote utile

Le vote à la proportionnelle permet de faire ça aussi.

permettre d'exprimer des choix négatifs…

La démocratie, ce n'est pas faire des choix négatifs (dire ce qu'on ne veut pas faire) mais faire des choix positifs (dire ce qu'on veut faire). Et vu l'offre politique actuelle, si tu ne trouves pas ton bonheur, c'est que tu n'as pas assez bien cherché.

Alors, je reformule : ça répond à quel besoin concret un système de vote plus complexe ? Qu'est-ce qu'un système de vote plus complexe permettrait que ne permet pas le système de vote actuel ?

Et ça répond à quel besoin concret l'introduction de dépouillement assisté par ordinateur ? Aucun, ça complique le processus, et les résultats on les a déjà à 20h.

Bref, pour que les 3èmes partis aient moins de pouvoir, il suffirait que les 2 premiers soient moins cons, ou que les représentants du peuple cessent d'être des godillots (pas gagné non plus!).

Généralement, quand il y a deux partis, c'est qu'il y a deux manières de voir les choses qui sont largement incompatibles. Donc, à partir de là, je vois mal comment ils pourraient se mettre d'accord. Mais dans la pratique, oui, ce qu'on voit dans beaucoup de pays d'Europe où les partis sociaux démocrates s'allient avec les partis conservateurs va dans ton sens. Et même en France, ça va arriver. Mais quand on en est là, on se dit qu'on est mal barré. Quand tu vois le SPD (sociaux démocrate) préférer faire alliance avec la CDU de Merkel plutôt qu'avec les Verts et Die Linke alors qu'il aurait pu pour former une majorité à gauche, et bien tu te poses franchement des questions. Et puis, à force de pratiquer ce genre d'alliance contre-nature, tu te retrouves avec le cas grec où le 3è devient premier tellement les deux premiers sont empêtrés dans la même logique.

Déja, la proportionnelle à la présidentielle, je demande à voir

Je supprime le président, et je le remplace, comme dans beaucoup d'endroits par un premier ministre issue des législatives. Ou mieux, un couple paritaire de premiers ministres (et on tire au sort pour savoir qui va à l'Elysée et qui va à Matignon).

Défendre la proportionnelle, c'est quand même nier les problèmes d'instabilité politique inhérents au système

Oui et non. Il faut évidemment mettre des garanties pour éviter que les majorités éclatent toutes les trois semaines. Par exemple, empêcher de quitter une majorité sans en proposer une alternative permet de prévenir très largement le yoyo.

quand on est troisième d'une élection, on ne devrait pas être en position de force pour négocier.

Pourquoi ? Ils doivent avoir la position qu'ils méritent et qui est proportionnelle au nombre d'électeurs, ça s'appelle un rapport de force et c'est au contraire un fonctionnement normal en démocratie.

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;