arnaudus a écrit 5545 commentaires

Les types qui développent par exemple des outils de calcul dans la recherche vont peut-être avoir besoin d'allouer des Go, et captureront std::bad_alloc.

En mode "my life", c'est un peu ce qui m'arrive de faire, et je ne capture pas les exceptions. Évidemment, ça dépend du contexte (est-ce que c'est un soft largement distribué ou est-ce un code one-shot pour un projet en interne, etc), mais j'ai l'impression que le cas général dans la communauté scienifique, c'est qu'on cherche plus un comportement reproductible qu'une robustesse à toute épreuve. Si en fonction du contexte, ton soft utilise des bouts de code qui ne sont exécutés qu'en cas de bad_alloc, tu n'as aucune garantie que de refaire tourner ton calcul le lendemain après avoir pourri l'étudiant malotru qui osait avoir eu l'idée de faire un calcul sur le cluster en même temps que toi te donnera le même résultat.

En tout cas, à mon niveau et pour ce que je fais, le comportement souhaitable reste un abort() violent avec éventuellement un message d'erreur, que ce soit pour un problème d'allocation mémoire, d'accès disque en lecture/écriture, d'accès réseau, ou n'importe quel truc qui ne fonctionne pas exactement comme il le devrait. Tu rends la main, l'utilisateur résoud le problème, et relance le truc. D'ailleurs, de toutes manières, quand il y a des problèmes de mémoire et que tu fais partie des coupables, en général il y a plus de chances de se faire shooter par l'OOM killer que de lever toi-même une bad_alloc.

Ceci dit, je conçois tout à fait que ce n'est pas forcément non plus ce que tu souhaites si tu développes des logiciels utilisés par des milliers de chercheurs, ou sur des dispositifs embarqués, ou sur des appareils dont l'utilisation coûte des milliers d'euros à la minute, ou sur des trucs de calculs intensifs qui prennent 60 jours à tourner sur des clusters à 200 nœuds. C'est juste que pour beaucoup d'applications scientifiques, je pense qu'il est préférable d'éviter les comportements créatifs en cas de problème.

Rassurez-moi, je n'ai pas la mémoire des pseudos, c'est toujours le même contributeur qui fait bunga-bunga aux principes fondamentaux de la grammaire de notre belle langue, ou il y a une épidémie?

La prochaine étape, ça va être des fils de discussion entre le.a mec.uf qui met tout en capitales, celui.lle qui met des accents plats, le.a pignouf.asse qui a décidé que le présent de l'indicatif était suffisant? Parce que si chacun y va de ses névroses orthotypographiques, on n'est pas sortis de l'auberge… Surtout que c'est totalement délétère, puisque le fond est intéressant.

Est-ce qu'on va demander aux fabricants de tondeuses de faire des tondeuses qui refusent de démarrer un dimanche?

Probablement pas, parce que ça demanderait des modifications techniques très importantes et coûteuses sur les tondeuses. Par contre, on a demandé aux fabricants de tondeuses d'empêcher la tondeuse de démarrer si on n'avait pas les deux mains sur la poignée.

Mais dans le même genre, on a demandé aux constructeurs de bus de mettre en place des antidémarrages à éthylotest. On a demandé aux constructeurs de GPS de mettre en place des mentions légales et des avertissements chiants pour dire "OKOK je n'y tripote pas en conduisant" (d'ailleurs, c'est typiquement les trucs sur lesquels on clique en conduisant). On aurait depuis très longtemps interdit la vente de voitures capables de rouler à plus de 130 km/h s'il n'y avait pas eu de puissants lobbys pour s'y opposer.

C'est quand même assez extrême comme point de vue de prétendre que l'implémentation par une mesure technique d'une restriction légale ou de sécurité est contraire à la liberté des utilisateurs, surtout quand on n'a pas d'exemple d'utilisation légitime du produit non-restreint. Il ya plein de choses débiles ou illégales qu'on t'interdit techniquement de faire, et la plupart des gens vivent avec. Par exemple je ne peux pas balancer plus de 500mA dans mon fil de terre, de quoi ERDF se mêle? Je ne peux pas rouler sans ceinture avec ma bagnole sans qu'elle fasse des bipbip stridents, de quoi le constructeur se mêle? Je ne peux pas dupliquer une clé SNCF, comment le fabricant peut-il savoir que je n'en ferai pas une utilisation légitime? Ça peut continuer indéfiniment, notre société considère qu'il est assez légitime de limiter, quand c'est possible, l'utilisation illégale ou dangereuse des outils qu'on peut acheter. Par exemple, ça permet d'éviter que tout le monde aille à tout bout de champ en justice pour faire respecter ses droits, et ça évite aussi de violer une règle sans le savoir. Ça se voit plus avec l'informatique, simplement parce qu'il est en général beaucoup plus facile de mettre en place de telles mesures avec un petit bout de code.

Et pour comparaison, je ne trouve pas que la comparaison avec les DRM soit bonne. Les DRM n'ont pas été mis en place pour protéger la collectivité d'une utilisation abusive d'un outil, ils servent à implémenter des limitations des outils souhaités par le constructeur, et absolument pas interdites par la loi ou la règlementation.

Le problème dans la manière dont tu présentes la chose, c'est que tu ne sembles pas proposer d'alternative, à part le fait de ne pas contrôler les émissions électromagnétiques.

Sur ce point, c'est un débat sans fin, et la loi repose toujours sur des contingences historiques et politiques propres à chaque pays. Il existe en France des règles sur la taille des couteaux qu'on peut avoir avec soi sur la voie publique, par exemple, alors qu'un couteau reste un outil qui peut servir à couper des légumes. Et à moins d'être totalement libertarien, on peut penser qu'il est légitime d'encadrer la vente et l'utilisation de trucs potentiellement dangereux (engrais qui peuvent être utilisés pour faire des bombes, poisons potentiels, armes potentielles, etc), ou même simplement potentiellement antisociales (bruit des pots d'échappement, etc).

Bien sûr, ces règles n'ont jamais empêché personne de motivé de contourner la loi. Mais d'un autre côté, ça décourage les débiles qui ne sont pas si motivés que ça, ça permet de donner une base légale à une interpellation (par exemple, sans ces restrictions, comment arrêter quelqu'un qui se fait contrôler avec de la nitroglycérine et des détonateurs dans sa bagnole?), et surtout, ça évite les accidents.

Une utilisation détournée assez évidente des cartes wifi, par exemple, serait la distribution de petits logiciels permettant d'étendre la bande passante au-delà de la bande légalement attribuée au Wifi. Dans les zones denses, il peut y avoir tellement de routeurs wifi qu'il devient compliqué de se caler sur un canal libre. Si tu pouvais t'inventer des nouveaux canaux comme tu voulais, tu aurais très vite une prolifération de crapwares Windows pour dépasser dans tous les sens et polluer l'environnement électromagnétique (après, j'avoue avoir aucune idée de l'efficacité de la transmission wifi sur des fréquences non-prévues à cet effet). Je suis certain que n'importe quel groupe de geek a déja des centaines d'idées sur l'exploitation non-prévue de telles antennes, et on pourrait imaginer que des restrictions logicielles un peu chiantes devraient en décourager pas mal.

En fait, tu préfèrerrais quoi? Que les dispositifs wifi contiennent du logiciel non-libre, ou qu'il existe une police électromagnétique qui tourne en camionettes banalisées pour trianguler les petits malins qui débordent? Tu voudrais vraiment payer des impôts pour contrôler ça, alors qu'il existe une solution qui repose sur les constructeurs? (en fait, oui, des gens comme nous pourraient vouloir ça, mais 99% de la population trouverait probablement ça complètement débile).

Bref, peut-être que le moins pire serait de disposer de firmwares open source signés, qui te permettent d'étudier le fonctionnement du truc, mais pas d'utiliser le matériel avec un firmware modifié. Mais si tu as d'autres solutions, je suis complètement preneur! Il faut juste proposer des solutions, parce que sinon, il n'y a aucune force à l'argument.

Mouais, il est aussi illicite de discriminer selon la couleur de peau ou la religion, mais pourtant l'annonce n'indique pas européen/africain/asiatique ni juif/musulman/athée/chrétien…

Moi je vois des problèmes très concrets avec une représentation interne qui suit exactement les spécifications du document XML. Ça veut dire que l'évolution du logiciel est totalement liée à l'évolution du standard—et donc, que l'indépendance vis-à-vis d'un standard concurrent est totale. Par ailleurs, je ne vois pas du tout dans ce cas comment supporter plusieurs standards, à moins d'avoir du code spécifique pour chacun des standards (autrement dit, quand on clique sur "gras", le bout de code appelé va être différent en fonction du type de fichier d'entrée).

De toutes manières, historiquement, LibreOffice/OpenOffice/StarOffice précède très largement l'idée même de document XML, c'est à dire que le format OpenOducment a probablement été défini à partir de la représentation interne des documents dans le code, et pas le contraire.

Du coup, j'ai l'impression que c'est injuste de reprocher à LibreOffice son manque de support d'OOXML. Il me semble évident que les logiciels qui ont été développés après la publication du standard OOXML ont pu calquer leur architecture sur le format, ce qui rend tout de suite la compatibilité plus facile. Je ne sais pas exactement comment LibreOffice gère les différents formats, mais aucune solution ne semble parfaite : soit on crée de moulinettes pour transformer l'OOXML en OpenDocument, puis OpenDocument vers OOXML, soit les deux formats sont importés dans la représentation interne de LibreOffice puis exportés (avec perte d'info pour les fonctionnalités d'OOXML non supportées), mais je dirais que les problèmes d'intercompatibilité sont principalement dûs à des contraintes d'architecture, et pas à une incompétence des developpeurs.

D'ailleurs, comment est-ce que OnlyOffice et al se débrouillent avec les documents odt?

Désolé de pourrir le fil avec une question idiote, mais je n'ai pas l'habitude des petites annonces, et je suis surpris par la mention "H/F": est-il réellement nécessaire de préciser quelque chose qui ne peut légalement pas être autrement? C'est un peu comme la mention "Sans colorants ni conservateurs conformément à la règlementation"?

duckduckgo par exemple, je l'utilise et j'en suis content, mais il faut se fier à leur bonne foi

Pas seulement, ddg est un méta-moteur de recherche, on peut éventuellement le voir comme une manière d'anonymiser ses recherches google, mais certainement pas comme une alternative à Google. Comme même les autres moteurs de recherche commerciaux vont sniffer Google, ça me parait compliqué de s'en passer.

Et puis, il faut bien réaliser que si Google souhaitait obtenir des infos sur vous, il pourrait même quand vous utilisez ddg. Pour des sites qui ne sont pas hyper-fréquentés, il suffit de croiser les remontées de Google analytics avec les réponses aux requêtes provenant de ddg.

Il faudrait analyser la gamme dans laquelle la fin de la chanson est jouée et se baser dessus.

Peut-être, mais je ne connais pas beaucoup de styles de musique occidentale où on n'a pas tendance à finir sur la tonalité du morceau, même quand ça module (et il n'y a pas beaucoup de modulation en pop, rock, etc), ça revient à la tonalité de départ sur la fin.

D'ailleurs, il faudrait peut-être que des spécialistes s'expriment là dessus, mais il me semble bien que classiquement, que si on ne termine pas par l'accord majeur de dominante, on n'enchaine pas forcément sur la nouvelle tonalité. Par exemple, dans les suites de Bach, on peut terminer sur une tierce picarde et enchainer sur une tonalité mineure ; inversement, les enchainements majeur/mineur se font sans transition particulière.

Ceci dit, la règle générale en musique classique reste de suivre les règles de la modulation pour enchainer les morceaux, les transitions se font entre tonalités proches, ou éventuellement entre mode majeur et mode mineur dans la même tonalité (ce qui s'entend pas mal quand même).

une boite se fait directement du pognon sur notre travail non rémunéré.

Je ne suis pas certain que tu aies bien compris ce qu'était le travail :-)

lol on doit pas du tout être de la même génération

C'est probablement insultant pour les gens de ta génération qui ont assez de maturité pour s'arrêter quand ils se rendent compte qu'ils ne comprennent rien à la discussion qu'ils ont lancée.

Parce que c'est bien connu, les autres industries sont tout à fait capables de se mettre d'accord sur des standards, de les implémenter, et de les respecter.

Quand tu changes des essuie-glaces, par exemple, tu choisis la taille… et tu te démerdes parce que les petits bitonios en plastique pour la fixation sont tous différents.

Quand tu achètes une cafetière à dosettes, bien entendu, elles utilisent toutes les mêmes dosettes et donnent toutes le même café.

Quand ton pot de peinture est terminé, bien entendu, tu peux acheter un pot d'une autre marque qui porte le même nom de couleur et tu auras exactement la même nuance.

La plupart du temps, il faut juste apprendre à vivre dans un monde imparfait. Il existe des normes, parfois les fabricants s'en foutent, parfois ils essayent de les implémenter, mais à moins d'avoir une très bonne raison pour le faire, il y a toujours des choses qui déconnent. Même quand le standard existe est est appliqué (par exemple les ampoules électriques), tu as la certitude que ton ampoule va rentrer dans le culot, mais parfois ça coince parce que le bulbe est trop gros, trop effilé, trop long ; et qu'à puissance égale tu peux avoir de grosses différences de température de couleur, ce qui fait que si tu veux un truc cohérent, il faut changer toutes tes ampoules en même temps.

S'il existait un organisme de vérification de conformité des navigateurs internet qui t'empêchait physiquement d'éditer un navigateur internet dans le monde entier tant qu'il ne passe pas un certain nombre de tests très stricts sur le respect des standards, alors peut-être qu'on aurait un peu plus de cohérence. Mais personne ne voudrait d'un truc aussi lourd et contraignant, c'est comme ça.

ben tant que tu n'ouvriras l'editeur de texte, il va le laisser en swap

Si c'est ce qu'il fait, ça n'est pas très intelligent. Ça veut dire que tu peux payer le coût de l'hibernation des heures après être sorti du sommeil.

manipuler un document dont tu ne comprends pas toute la logique.

C'est peut-être ce que dit la théorie, mais en pratique, ça ne peut fonctionner que pour des modifs hyper-mineures. Prend au pif un tableau XHTML

<table>
   <tr>
      <th width="20%" align="center">A</th>
      <th width="20%" align="center">B</th>
   </tr>
   <tr>
      <td align="center" valign="top">C</td>
      <td align="center" valign="top">D</td>
  </tr>
</table>

Imagine que ton éditeur ne comprend pas align. Ton utilisateur te demande de dupliquer la deuxième ligne du tableau. Tu vas faire quoi? 1) Dupliquer les attributs que tu ne comprends pas? Ou alors 2) créer une ligne sans attributs d'alignement?

Dans le cas 1), tu vas te mettre dans une situation où le document est potentiellement corrompu, invalide, ou ininterprétable par l'autre logiciel : par définition, les arguments que tu ne comprends pas, ils devraient peut être n'apparaitre qu'une fois, ou que dans un contexte particulier.

Dans le cas 2), tu es quasiment certain de produire une mise en page cassée. Dans ton logiciel qui n'aligne pas les tableaux, rien ne sera aligné, et le tableau sera cohérent. Mais dans un logiciel qui comprend tout le standard, alors la mise en page sera pétée. Au passage, rien ne te garantit que ton document sera valide, car il est possible que l'attribut que tu n'as pas compris n'ait de sens que s'il est présent dans toutes les lignes.

Et puis, encore une fois, je ne sais pas comment fonctionne LibreOffice ou les autres traitements de texte en interne, mais il est plus que probable que leur fonctionnement n'implique pas de lier toutes les opérations "en live" à la modification d'un arbre XML. Il me semble probable que le logiciel ait une représentation interne (sous forme de classes par exemple) des différents éléments, et que l'arbre XML soit créé à l'enregistrement du fichier—du coup, la représentation interne ne peut pas garder les nœuds incompris et les manipuler.

Tu peux aussi indiquer à l'utilisateur que tu ne comprends pas tout le document et qu'il va perdre de l'information…

Sous LibreOffice, c'est exactement ce qu'on te dit quand tu manipules des fichiers OOXML.

Il est tout à fait possible d'innover sur l'interface, l’ergonomie

Oui oui, comme les lessives qui innovent sur le colorant et le parfum. Je sais bien que la plupart des gens considèrent que c'est de l'innovation, mais il ne faut pas charrier : les logiciels de traitement de texte ont besoin d'innover sur bien plus que l'interface pour avoir un rendu acceptable.

contrairement à LO qui convertit le document dans son format interne et perd de l'information au passage…

Ça parait quand même très très compliqué de faire autrement, non? Bien sûr, tu peux créer un logiciel capable de modifier de manière marginale un document sans changer sa structure, mais dès que tu souhaites toucher à des choses fondamentales (mise en page, changement de structure du document…), je ne vois pas comment tu peux t'épargner l'étape de charger la totalité du fichier dans ton abstraction interne. Une fois à cette étape là, plus moyen de revenir en arrière… Bien sûr, tu peux imaginer un système qui essaye de remettre les nœuds incompris à peu près là où ils étaient, mais je ne vois pas quelle garantie tu peux avoir qu'ils aient toujours un sens…

la manip MSword -> Libreoffoce.writer -> MSword fait perdre de l'information de mise en page.

Ça ne prouve pas grand chose, ça peut être un bug dans LibreOffice ou dans MSWord, ou ça peut venir de l'existence de propriétés documentées dans OOXML qui ne sont pas prises en charge dans le format odt et/ou par Libreoffice.

De toutes manières, ces formats sont beaucoup trop complexes pour être interchangeables. Pour cela, il faudrait que toutes les possibilités d'OOXML se retrouvent dans OpenDocument et vice-versa, ET que les logiciels MS Word et Libre Office soient capables de gérer l'ensemble de ces possibilités. Le mieux qu'on puisse espérer, c'est que chaque logiciel soit capable de lire les deux formats, et d'importer le sous-ensemble commun entre les deux.

À la base, le principe même de la normalisation des formats est contradictoire avec la notion de format natif. Ça bloque l'évolution des fonctionnalités des logiciels, et ça empêche d'innover sur le fond par rapport à ses concurrents.

Parce que la présence d'une méthode virtuelle implique la génération d'une vtable, qui a un impact sur les performances.

Dans ce cas, le concept même de coder en C++ a un impact sur les performances. Parce que si tu n'utilises pas le polymorphisme, ni la STL, ni les exceptions, ni les templates et que tu préfères utiliser des pointeurs nus et des macros, alors ça ressemble furieusement à ce que certains appellelent du C/C++, qui n'est en fait ni du C ni du C++.

Au passage, la règle pourrait bien être que les destructeurs d'une classe qui a au moins une méthode virtuelle sont virtuels. Ou de définir un mot clé "nonvirtual" pour les 0.01% des cas où on veut explicitement éviter la création d'une vtable.

Portabilité & Compatibilité (oui, je sais) avec la famille execXY() standardisée par POSIX

Dans ce cas, je ne vois pas le problème à surcharger la fonction main, une en int main(int, char**) et une en bool main(vector<string>). Encore une fois, si tu veux faire du C/C++, tu peux utiliser la version C, le compilo peut bien voir quelle version tu utilises.

des gens qui n'ont rien à faire de la performance et de la portabilité, qui ne sont pas la cible première de C++?

On pourrait débattre indéfiniment sur la cible première du C++, mais la performance et la portabilité ne peuvent pas être les deux seuls critères ; autrement, les gens feraient du C. Le C++, c'est avant tout la POO, la programmation générique, l'encapsulation, la STL, et tous les petits trucs du C++ moderne (lambda, inférence de type, shared_pointers, etc). Je t'accorde qu'il existe des gens comme toi qui interprètent le langage en tant que C amélioré, et notamment qui pondèrent l'utilisation d'un certain nombre de fonctionnalités du langage par les coûts induits en temps d'exécution et en mémoire. Mais il faut aussi voir que pour une très vaste communauté, ces choses n'ont aucun intérêt par rapport aux avantages de l'encapsulation, de la gestion des erreurs, ou des vérifications de types faites à la compilation?

Honnêtement, je ne comprends pas à quelle catégorie d'erreur tu faisais allusion (dans quelle mesure est-ce que la critique de la non-gestion des modules est-elle obsolète?).

Tu as une manière "officielle" de gérer les en-têtes, c'est 1) d'inclure les fichiers .h à l'aide d'une directive du pré-compilateur, ce qui reste un procédé hyper-bourrin (en gros, un copié-collé du header, qui sera recompilé pour chaque .cpp), et 2) d'inclure "à la main" des directives du pré-compilateur pour s'assurer que le header ne sera inclus qu'une fois. Autant dire que les modules ne sont absolument pas gérés, il faut tout faire soi-même. Le langage ne sait même pas ce qu'est un module, la seule chose qu'il sait faire c'est d'acceper une déclaration dans le même fichier an amont de la définition. C'est tellement une limite du langage que les compilos ont développé des pragma (à l'origine absolument pas standard) pour faciliter un peu la vie.

À mes yeux, ta réponse confirme simplement ce que d'autres essayent de dire dans ce fil : en C++, la gestion des modules est quasi-inexistante, et repose sur un procédé obsolète et bancal. Les pragma once et autres sucres syntaxiques ne résolvent pas le problème, et tu ne fais qu'insister sur le fait qu'il s'agit de solutions techniquement bancales. Du coup, on est tous d'accord, j'ai juste l'impression que tu trouves le système par défaut acceptable (et, de facto, il l'est puisqu'on l'utilise tous). C'est juste un peu dommage que tu ne sembles pas voir l'intérêt d'un système de modules moderne.

je lis des choses qui sont inexactes

Du coup, tu peux les corriger avec des faits? C'est plutôt ça qui serait utile.

En particulier, les choses qui étaient vraies et qui ne sont plus vraies, c'est tout à fait possible qu'on puisse ne pas être au courant. Une telle erreur peut être faite de bonne foi, et si tu as l'info permettant de la rectifier, je ne vois pas pourquoi te priver de répondre poliment.

Peut-être, mais certains sont les imbéciles de beaucoup de gens, ce qui veut probablement dire beaucoup.

Et puis le jour où il le découvre le gugus s'insurgera (à juste titre) et il tentera de commettre un meurtre et ira en prison

L'argument, c'est qu'il ne faut pas être méchant avec les trolls, parce qu'on ne sait jamais s'il ne vont pas pêter une diurite et buter des gens?

En fait, c'est un appel à la soumission, ton truc. Ton voisin est violent? Ne le contrarie pas, c'est un coup à prendre un bourre-pif. Ton patron te harcèle? Ne proteste pas, c'est un coup à te faire virer.

Je ne suis pas psychiatre. Je ne peux pas savoir si mon interlocuteur est violent ou non, s'il a pris ses médicaments, s'il utilise les forums comme thérapie ou au contraire si ça risque de renforcer sa névrose. Le plus sain, c'est d'essayer en douceur d'inciter les gens qui ont des problèmes à se faire soigner, et d'éviter au maximum qu'ils puissent interagir avec les gens qui veulent savoir pourquoi leur programme ne compile pas, et qui pourraiernt réagir d'une manière peu constructive.

Au passage, une certaine forme de névrose est quand même tolérée dans le milieu du libre. Par contre il faut coder comme un dieu pour se permettre d'insulter les gens.

Je pense que personne n'a jamais suggéré de mettre en place un test anti-névrosé et de leur interdire la lecture ou la contribution. C'est juste que quand un historique de contributions substantiel prouve que leurs contributions sont évaluées de manière très négative et qu'ils nuisent à la tenue des discussions, alors il faut protéger les contributeurs "normaux" aussi, parce que l'objectif du site n'est pas de fournir un espace de thérapie.

S’il y a effectivement du code qui peut être cassé à chaque évolution du langage, on est très loin de ce que tu décris et de la fréquence que tu sembles indiquer.

Les évolutions du langage, c'est tous les 2 ou 3 ans. Et ça m'arrive très souvent de passer du temps à rebricoler des trucs pour compiler du vieux code, simplement parce que les compilateurs corrigent des bugs d'implémentation de la norme (des trucs qui émettaient un warning et qui donnent une erreur, des syntaxes illicites qui passaient mais qui ne passent plus). Évidemment, pour un projet à soi, on s'en fout (une demi-journée tous les trois ans, ça n'est pas la mer à boire), mais pour l'ensemble de l'écosystème, c'est juste chiant. Et du coup, l'idée de compiler du vieux code non-trivial sans mettre les mains dans le cambouis, ça ne fonctionne pas. Alors un truc dégueu (genre goto) qui devient déprécié, ça gène qui exactement? Surtout que tu pourrais avoir une option du compilo pour dire "compile-moi ça quand même".

Le problème, c'est que C++ ne veut pas choisir entre la rétrocompatibilité C et le C with classes d'un côté, et un langage objet moderne de l'autre côté. Est-ce qu'on peut promouvoir indéfiniment ce modèle chimérique? Ça intéresse qui exactement de pouvoir faire un printf avec un argument template? Évidemment, tu peux lire des bouquins, des guidelines, des tutoriels, mais si le langage te transmets l'idée qu'il y a 75 manières de faire quelque chose et qu'il est neutre à ce sujet, il y a un problème. Si la cohérence du language tient au respect de quelques bonnes pratiques qui ne sont pas implémentées par défaut, alors il y a un problème (par exemple, pourquoi les destructeurs ne sont-ils pas virtuels par défaut?).

Sur le fond, la question n'est pas sur la complexité de certaines techniques très poussées qui ne servent qu'à une toute petite fraction des développeurs. C'est peut-être cool de pouvoir surcharger "new" ou "*", personnellement je m'en fous. Par contre, il est anormal que cette souplesse s'accompagne de bizarreries historiques portant sur du code complètement courant (typiquement, les arguments de main), des syntaxes WTF, ou des subtilités pédantesques (personnellement, j'aime bien le comportement d'un bool qu'on a oublié d'initialiser).

Par contre ce que tu appelles un gadget reste utile pour les contributeurs qui, sans être des trolls, ont parfois un comportement qui gène certains.

L'un n'empêche pas l'autre, bien sûr!

Et on n'est pas des machines non plus, quelqu'un comme Zenitram pourrait être artificiellement protégé de l'algo anti-spam, parce qu'il est énervant mais (parfois) constructif.

voir ce que j'ai dit ci-dessus. Et avec la pénurie d'IPV4, ça risque d'arriver de plus en plus souvent.

Je pense que tu as un peu de mal à évaluer les ordres de grandeur. Il y a environ 100 ouvertures de compte par mois. Même s'il n'y avait que dix millions d'adresses IP en France et que ça tournait tous les jours, la probabilité de se retrouver le jour de l'ouverture de compte avec la même IP que quelqu'un qui a ouvert un compte dans les 30 derniers jours serait de 0.000003. En moyenne, si mes calculs sont bons, une collison devrait arriver au rythme effréné d'une tous les 11000 mois, soit une fois tous les 926 ans.

Et donc, une fois tous les 926 ans, quelqu'un devra attendre le lendemain pour ouvrir un compte sur linuxfr. Y'a pas à dire, c'est problématique.