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).
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.
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.
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.
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.
Loin de moi de douter de la popularité de Linuxfr, mais tu suggères réellement que tu crains de ne pas pouvoir créer de compte parce que tu risques d'avoir la malchance de récupérer aléatoirement l'IP de quelqu'un qui vient de se faire bannir?
Même derrière un proxy, la question n'est que de bloquer la création de compte pendant un certain délai (15 jours?) à partir de la dernière IP d'un compte banni. Les chances que ça gène quelqu'un sont quand même minces…
Je pense que c'est exactement pour éviter de telles situations que certains utilisateurs devraient être bannis. Le harcèlement par des trolls peut être très mal vécu, et on peut vouloir garantir un minimum de confort aux lecteurs réguliers.
D'un autre côté, un forum ouvert, c'est quand même un peu comme un match de rugby. Le principe, c'est quand même de prendre des gnons et de les rendre, tout en ne perdant pas de vue que ça n'est pas l'objectif. Si on se sent un peu fragile, c'est peut-être assez dangereux de se lancer sans protection dans une conversation trollifère sur les choix alimentaires.
C'est pas un problème que quelque chose d'aussi courant soit si complexe
Bien sûr que si, et je trouve qu'il y a un peu de mauvaise foi dans les réponses du type "ouhlalala, ça restreindrait la liberté de l'utilisateur et ça biaiserait la philosophie du langage si on faisait ça". La gestion des en-tête en C++ est assez ridicule, c'est au programmeur de bricoler des directives au pré-processeur tout ça parce que le langage n'est pas fichu de reconnaitre un fichier de header. Ça gênerait la liberté de qui exactement si le langage était capable de reconnaitre la stucture de 99.9999% des programmes en C++? Il y a des gens qui "#include" des trucs autres que des .h?.
Avec des raisonnements comme ça, on ne change jamais rien. La liberté de l'utilisateur a bon dos… Y compris dans la justification de la non-dépréciation de syntaxes obsolètes qui n'ont aucune justification (goto, void*, etc). Il y a du code de 40 ans qui compile grâce à ces trucs? Qu'est-ce qu'on s'en fout, il est en général indispensable d'adapter le code de l'année d'avant quand on change de version de gcc de toutes manières…
L'idée n'est pas forcément d'empêcher techniquement l'enquiquineur de venir, parce qu'en effet, c'est très compliqué. Mais d'expérience, si on arrive à lui mettre des bâtons dans les roues, il va se lâcher.
Une possibilité, par exemple, c'est qu'une fois atteint une limite de karma négatif, le compte est gelé et tous les messages notés négativement sont supprimés avec la mention ("compte fermé pour trollage") quand quelqu'un a répondu, et disparition totale quand personne n'a répondu. L'avantage, c'est que si le troll a exceptionnellement contribué de manière positive à une discussion, alors son message est conservé. C'est juste que tous ses messages "pourris" sont retirés.
Ensuite, il suffit de compliquer un peu la recréation de comptes. Par exemple, ne pas pouvoir recréer un compte avec la même adresse email, ou limiter la création de comptes à partir de la même IP. Bien sûr, techniquement, ça n'empêche pas la création de comptes, mais ça va demander au malandrin de passer du temps à se créer un email jetable, à trouver un moyen de changer d'IP, etc.
Mais bon, je pense que le plus efficace reste quand même la disparition des messages. Évidemment, ça ne peut fonctionner que si ça disparait pour tout le monde, et pas seulement de quelques utilisateurs qui usent d'un gadget. L'ultime but du troll est d'exister. S'il sévit une journée entière, qu'il se récolte un karma de -10000, et que le soir toutes ses contributions disparaissent, le gars aura perdu sa journée. On saura tous qu'il est inutile de lui répondre car il va disparaitre, il va donc parler tout seul. Un tel effacement numérique est probablement tellement insupportable pour un troll qu'il ne va pas rester longtemps : rien ne sert de gueuler contre la censure, contre les autres, contre les modérateurs, chaque jour, tout ce que le mec a fait disparait.
Le comble du bonheur serait à mon avis de ne pas fermer son compte par une procédure lourde. Juste faire en sorte que quand il se loggue, il voit ses messages comme si de rien n'était. Pour lui ça ne changerait rien, il continuerait à troller, vociférer, intervenir partout. Sauf que personne d'autre que lui ne voit ses messages.
C'est aussi un avantage de pouvoir faire les choses comme on veut, sans être forcé à suivre les choix des concepteurs du langage.
Il y a une différence entre "être forcé de suibre les choix des concepteurs" et être guidé vers les bonnes pratiques.
Prend par exemple le char** dans le main(). C'est quand même super paradoxal, non? Ça ne semblerait pas plus cohérent de pouvoir obtenir un std::vector<std::string>? Le langage envoie des signaux contradictoires tout le temps.
Je trouve qu'il y a quand même quelques problèmes avec les comptes à -10. Ça pourrit quand même l'ambiance de voir ces posts qui dévient systématiquement les discussions dans des directions qui ne mènent à rien, et tout le monde n'a pas forcément la force de caractère de les ignorer (moi par exemple, j'en suis incapable. Quand quelqu'un poste un commentaire débile mettant en cause l'auteur d'un journal intéressant par exemple, je ne peux pas m'empêcher de répondre pour apporter mon soutien aux gens qui font l'effort d'être constructifs).
Quelqu'un qui n'est pas foutu d'avoir un seul commentaire constructif depuis le début de son compte a quand même un problème : soit c'est un pur troll, soit il a un problème psychiatrique. Je me souviens avoir quitté Wikipédia en partie pour des raisons similaires, on peut constituer une communauté ouverte tout en se débarrassant des nuisibles, ça n'est pas incompatible. C'est même franchement débile de ne pas le faire quand l'objectif de la personne en question est de mettre le bordel. Et quand c'est juste quelqu'un qui est mal dans ses baskets, j'aimerais qu'on m'explique quel bénéfice il peut en tirer de se voir affubler de scores de -28 (autant aller vers un site sans modération par les utilisateurs, parce que ça ne rend service à personne de se faire humilier publiquement).
Quelque part, entre perdre un troll inutile et perdre des contributeurs réguliers saoûlés par les pages de discussions qui tournent en rond, je trouve qu'il n'y a pas photo. Ça m'est déja arrivé de me prendre des -10 parce que j'avais une opinion marginale par rapport aux autres contributeurs, mais 1) ça veut probablement dire que je ne l'ai pas exposée correctement, et 2) ça n'arrive pas à tous les commentaires. Quand ça arrive tout le temps, c'est simplement que les contributions de la personne ne sont pas appréciées par les lecteurs, et c'est mauvais pour le site.
Il faut quand même ne pas oublier que la liberté d'expression, ça veut dire qu'on ne peut pas être inquiété par l'État pour ce qu'on dit. Ça n'implique pas du tout que quiconque soit obligé de lire ou de publier des inepties.
Avec les fusibles à l'ancienne, retirer le fusible ne faisait que de débrancher la phase, ce qui permettait en théorie une fuite de courant dans le neutre. J'ai déja vu ça, c'est bizarre de voir le tournevis testeur s'allumer quand on a coupé le fusible, mais je n'ai jamais vu de cas où il y avait assez de jus dans le neutre pour que ça puisse être dangereux (ceci dit, en rénovation, il ne faut pas faire d'hypothèse sur la compétence ou même la logique de l'installateur précédent…).
Les petit disjoncteurs récents coupent à la fois la phase et le neutre, et je trouve que c'est une excellente raison pour couper le circuit correctement plutôt que de faire confiance à l'interrupteur.
C'est quand même un chouilla plus complexe. Le C++ est un langage très souple, et on peut en faire à peu près n'importe quoi tant qu'on respecte la syntaxe de base. Par exemple, rien n'oblige à utiliser des classes, ni à utiliser la STL. Inversement, des mécanismes pourtant basiques ne sont pas inclus dans le standard, par exemple les directives préprocesseur pour éviter d'inclure plusieurs fois les headers.
Bref, un langage ne peut pas te prémunir contre le fait de coder n'importe comment. Ce qu'on peut reprocher au C++, c'est de ne même pas définir la manière correcte de faire les choses, ce qui fait qu'il n'est jamais clair si on fait les choses correctement ou non. Surtout qu'une manière correcte de faire va devenir incorrecte avec l'évolution du standard, ce genre de choses.
[^] # Re: Harmonie ?
Posté par arnaudus . En réponse à la dépêche Sortie de la bibliothèque d’analyse musicale Bliss 1.0. Évalué à 3.
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).
[^] # Re: Money makes the world go round
Posté par arnaudus . En réponse au journal Les routeurs Turris Omnia sont livrés. Évalué à 5.
Je ne suis pas certain que tu aies bien compris ce qu'était le travail :-)
[^] # Re: Money makes the world go round
Posté par arnaudus . En réponse au journal Les routeurs Turris Omnia sont livrés. Évalué à 7.
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.
[^] # Re: De la difficulté à obtenir un rendu [...] HTML, cohérent entre les différentes plateformes
Posté par arnaudus . En réponse au journal De la difficulté à obtenir un rendu SVG, voire HTML, cohérent entre les différentes plates‐formes. Évalué à 10.
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.
[^] # Re: mon avis
Posté par arnaudus . En réponse au message Swap utilisé au réveil du PC. Évalué à 2.
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.
[^] # Re: Paradoxale ?
Posté par arnaudus . En réponse à la dépêche ONLYOFFICE ouvre le code source des éditeurs de bureau. Évalué à 8.
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
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.
Sous LibreOffice, c'est exactement ce qu'on te dit quand tu manipules des fichiers OOXML.
[^] # Re: Paradoxale ?
Posté par arnaudus . En réponse à la dépêche ONLYOFFICE ouvre le code source des éditeurs de bureau. Évalué à 8.
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.
[^] # Re: Paradoxale ?
Posté par arnaudus . En réponse à la dépêche ONLYOFFICE ouvre le code source des éditeurs de bureau. Évalué à 7.
Ç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…
[^] # Re: Paradoxale ?
Posté par arnaudus . En réponse à la dépêche ONLYOFFICE ouvre le code source des éditeurs de bureau. Évalué à 1.
Ç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.
[^] # Re: Donc pour résumer…
Posté par arnaudus . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 2.
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.
Dans ce cas, je ne vois pas le problème à surcharger la fonction main, une en
int main(int, char**)et une enbool 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.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?
[^] # Re: Donc pour résumer…
Posté par arnaudus . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 5.
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.
[^] # Re: Donc pour résumer…
Posté par arnaudus . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 2.
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.
[^] # Re: Modération laxiste
Posté par arnaudus . En réponse au sondage La modération a posteriori des contenus et commentaires problématiques sur LinuxFr.org. Évalué à 4.
Peut-être, mais certains sont les imbéciles de beaucoup de gens, ce qui veut probablement dire beaucoup.
[^] # Re: Comptes à -10
Posté par arnaudus . En réponse au sondage La modération a posteriori des contenus et commentaires problématiques sur LinuxFr.org. Évalué à 5. Dernière modification le 04 octobre 2016 à 18:01.
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.
[^] # Re: Donc pour résumer…
Posté par arnaudus . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 5.
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).
[^] # Re: Comptes à -10
Posté par arnaudus . En réponse au sondage La modération a posteriori des contenus et commentaires problématiques sur LinuxFr.org. Évalué à 5.
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.
[^] # Re: Comptes à -10
Posté par arnaudus . En réponse au sondage La modération a posteriori des contenus et commentaires problématiques sur LinuxFr.org. Évalué à 10.
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.
[^] # Re: Comptes à -10
Posté par arnaudus . En réponse au sondage La modération a posteriori des contenus et commentaires problématiques sur LinuxFr.org. Évalué à 3.
Loin de moi de douter de la popularité de Linuxfr, mais tu suggères réellement que tu crains de ne pas pouvoir créer de compte parce que tu risques d'avoir la malchance de récupérer aléatoirement l'IP de quelqu'un qui vient de se faire bannir?
Même derrière un proxy, la question n'est que de bloquer la création de compte pendant un certain délai (15 jours?) à partir de la dernière IP d'un compte banni. Les chances que ça gène quelqu'un sont quand même minces…
[^] # Re: Modération laxiste
Posté par arnaudus . En réponse au sondage La modération a posteriori des contenus et commentaires problématiques sur LinuxFr.org. Évalué à 6.
Je pense que c'est exactement pour éviter de telles situations que certains utilisateurs devraient être bannis. Le harcèlement par des trolls peut être très mal vécu, et on peut vouloir garantir un minimum de confort aux lecteurs réguliers.
D'un autre côté, un forum ouvert, c'est quand même un peu comme un match de rugby. Le principe, c'est quand même de prendre des gnons et de les rendre, tout en ne perdant pas de vue que ça n'est pas l'objectif. Si on se sent un peu fragile, c'est peut-être assez dangereux de se lancer sans protection dans une conversation trollifère sur les choix alimentaires.
Non c'est sûr, c'est constructif.
[^] # Re: Donc pour résumer…
Posté par arnaudus . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 5.
Bien sûr que si, et je trouve qu'il y a un peu de mauvaise foi dans les réponses du type "ouhlalala, ça restreindrait la liberté de l'utilisateur et ça biaiserait la philosophie du langage si on faisait ça". La gestion des en-tête en C++ est assez ridicule, c'est au programmeur de bricoler des directives au pré-processeur tout ça parce que le langage n'est pas fichu de reconnaitre un fichier de header. Ça gênerait la liberté de qui exactement si le langage était capable de reconnaitre la stucture de 99.9999% des programmes en C++? Il y a des gens qui "#include" des trucs autres que des .h?.
Avec des raisonnements comme ça, on ne change jamais rien. La liberté de l'utilisateur a bon dos… Y compris dans la justification de la non-dépréciation de syntaxes obsolètes qui n'ont aucune justification (goto, void*, etc). Il y a du code de 40 ans qui compile grâce à ces trucs? Qu'est-ce qu'on s'en fout, il est en général indispensable d'adapter le code de l'année d'avant quand on change de version de gcc de toutes manières…
[^] # Re: Comptes à -10
Posté par arnaudus . En réponse au sondage La modération a posteriori des contenus et commentaires problématiques sur LinuxFr.org. Évalué à 5.
L'idée n'est pas forcément d'empêcher techniquement l'enquiquineur de venir, parce qu'en effet, c'est très compliqué. Mais d'expérience, si on arrive à lui mettre des bâtons dans les roues, il va se lâcher.
Une possibilité, par exemple, c'est qu'une fois atteint une limite de karma négatif, le compte est gelé et tous les messages notés négativement sont supprimés avec la mention ("compte fermé pour trollage") quand quelqu'un a répondu, et disparition totale quand personne n'a répondu. L'avantage, c'est que si le troll a exceptionnellement contribué de manière positive à une discussion, alors son message est conservé. C'est juste que tous ses messages "pourris" sont retirés.
Ensuite, il suffit de compliquer un peu la recréation de comptes. Par exemple, ne pas pouvoir recréer un compte avec la même adresse email, ou limiter la création de comptes à partir de la même IP. Bien sûr, techniquement, ça n'empêche pas la création de comptes, mais ça va demander au malandrin de passer du temps à se créer un email jetable, à trouver un moyen de changer d'IP, etc.
Mais bon, je pense que le plus efficace reste quand même la disparition des messages. Évidemment, ça ne peut fonctionner que si ça disparait pour tout le monde, et pas seulement de quelques utilisateurs qui usent d'un gadget. L'ultime but du troll est d'exister. S'il sévit une journée entière, qu'il se récolte un karma de -10000, et que le soir toutes ses contributions disparaissent, le gars aura perdu sa journée. On saura tous qu'il est inutile de lui répondre car il va disparaitre, il va donc parler tout seul. Un tel effacement numérique est probablement tellement insupportable pour un troll qu'il ne va pas rester longtemps : rien ne sert de gueuler contre la censure, contre les autres, contre les modérateurs, chaque jour, tout ce que le mec a fait disparait.
Le comble du bonheur serait à mon avis de ne pas fermer son compte par une procédure lourde. Juste faire en sorte que quand il se loggue, il voit ses messages comme si de rien n'était. Pour lui ça ne changerait rien, il continuerait à troller, vociférer, intervenir partout. Sauf que personne d'autre que lui ne voit ses messages.
[^] # Re: Donc pour résumer…
Posté par arnaudus . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 5.
Il y a une différence entre "être forcé de suibre les choix des concepteurs" et être guidé vers les bonnes pratiques.
Prend par exemple le
char**dans le main(). C'est quand même super paradoxal, non? Ça ne semblerait pas plus cohérent de pouvoir obtenir unstd::vector<std::string>? Le langage envoie des signaux contradictoires tout le temps.# Comptes à -10
Posté par arnaudus . En réponse au sondage La modération a posteriori des contenus et commentaires problématiques sur LinuxFr.org. Évalué à 10.
Je trouve qu'il y a quand même quelques problèmes avec les comptes à -10. Ça pourrit quand même l'ambiance de voir ces posts qui dévient systématiquement les discussions dans des directions qui ne mènent à rien, et tout le monde n'a pas forcément la force de caractère de les ignorer (moi par exemple, j'en suis incapable. Quand quelqu'un poste un commentaire débile mettant en cause l'auteur d'un journal intéressant par exemple, je ne peux pas m'empêcher de répondre pour apporter mon soutien aux gens qui font l'effort d'être constructifs).
Quelqu'un qui n'est pas foutu d'avoir un seul commentaire constructif depuis le début de son compte a quand même un problème : soit c'est un pur troll, soit il a un problème psychiatrique. Je me souviens avoir quitté Wikipédia en partie pour des raisons similaires, on peut constituer une communauté ouverte tout en se débarrassant des nuisibles, ça n'est pas incompatible. C'est même franchement débile de ne pas le faire quand l'objectif de la personne en question est de mettre le bordel. Et quand c'est juste quelqu'un qui est mal dans ses baskets, j'aimerais qu'on m'explique quel bénéfice il peut en tirer de se voir affubler de scores de -28 (autant aller vers un site sans modération par les utilisateurs, parce que ça ne rend service à personne de se faire humilier publiquement).
Quelque part, entre perdre un troll inutile et perdre des contributeurs réguliers saoûlés par les pages de discussions qui tournent en rond, je trouve qu'il n'y a pas photo. Ça m'est déja arrivé de me prendre des -10 parce que j'avais une opinion marginale par rapport aux autres contributeurs, mais 1) ça veut probablement dire que je ne l'ai pas exposée correctement, et 2) ça n'arrive pas à tous les commentaires. Quand ça arrive tout le temps, c'est simplement que les contributions de la personne ne sont pas appréciées par les lecteurs, et c'est mauvais pour le site.
Il faut quand même ne pas oublier que la liberté d'expression, ça veut dire qu'on ne peut pas être inquiété par l'État pour ce qu'on dit. Ça n'implique pas du tout que quiconque soit obligé de lire ou de publier des inepties.
[^] # Re: Modération laxiste
Posté par arnaudus . En réponse au sondage La modération a posteriori des contenus et commentaires problématiques sur LinuxFr.org. Évalué à 3.
Avec les fusibles à l'ancienne, retirer le fusible ne faisait que de débrancher la phase, ce qui permettait en théorie une fuite de courant dans le neutre. J'ai déja vu ça, c'est bizarre de voir le tournevis testeur s'allumer quand on a coupé le fusible, mais je n'ai jamais vu de cas où il y avait assez de jus dans le neutre pour que ça puisse être dangereux (ceci dit, en rénovation, il ne faut pas faire d'hypothèse sur la compétence ou même la logique de l'installateur précédent…).
Les petit disjoncteurs récents coupent à la fois la phase et le neutre, et je trouve que c'est une excellente raison pour couper le circuit correctement plutôt que de faire confiance à l'interrupteur.
[^] # Re: Donc pour résumer…
Posté par arnaudus . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 4.
C'est quand même un chouilla plus complexe. Le C++ est un langage très souple, et on peut en faire à peu près n'importe quoi tant qu'on respecte la syntaxe de base. Par exemple, rien n'oblige à utiliser des classes, ni à utiliser la STL. Inversement, des mécanismes pourtant basiques ne sont pas inclus dans le standard, par exemple les directives préprocesseur pour éviter d'inclure plusieurs fois les headers.
Bref, un langage ne peut pas te prémunir contre le fait de coder n'importe comment. Ce qu'on peut reprocher au C++, c'est de ne même pas définir la manière correcte de faire les choses, ce qui fait qu'il n'est jamais clair si on fait les choses correctement ou non. Surtout qu'une manière correcte de faire va devenir incorrecte avec l'évolution du standard, ce genre de choses.