rewind a écrit 3416 commentaires

Oui, il y a une raison, je l'avais expliqué un peu dans la dépêche. La raison principale, c'est le conservatisme du principal mainteneur sur les évolutions possibles (y compris des évolutions triviales) et le fait qu'il refuse d'accepter que SFML est utilisée à 99% pour des jeux (et donc il refuse tout ce qui est lié à la programmation des jeux).

J'ai oublié le principal : mettre quelques liens vers le projet !

• le code source sur github
• la documentation en ligne de la version 0.2.0

Du coup, j'ai voulu faire un tour pour voir à quoi ça pouvait ressembler le code de Ryzom et notamment ce bout de code pour les mots de passe. J'ai été incapable de trouver le dépôt, s'il existe. J'ai fouillé pendant 10 minutes sur tous les sites Ryzom sans trouver quoi que ce soit. Y a-t-il un dépôt public ou c'est moi qui suis trop mauvais ?

préférez l'ICIJ

Le partenaire de l'ICIJ en France, c'est Le Monde, qui est tenu, comme quasiment tous les autres journaux, par des millionnaires. Tu crois vraiment que tu reçois une information honnête et impartiale de la part du Monde ? Je prends le dernier exemple en date, les Panama Papers : aucun américain cité dans les articles du Monde. Pourtant, je pense qu'il y en avait des américains dans cette liste (et dans d'autres pays, comme l'Allemagne, ils ont été cités). Beaucoup de gens ont demandé à ce que la liste complète soit rendue publique (et ça a été fait) parce qu'il y a un gros déficit de confiance envers les journalistes, d'où qu'ils viennent. Et d'ailleurs dans ce cas de figure, ça me semble impossible de ne pas donner d'informations nominatives.

Bref, je ne me prononcerai pas sur Wikileaks, je pense qu'il y a à dire sur leurs méthodes, mais dire qu'il faut préférer des journalistes aux ordres de leurs patrons millionaires, et qui divulguent les informations quand ça les chante, et au fur et à mesure pour amener des clics sur leurs sites, non merci. Les méthodes des uns n'ont pas l'air de valoir mieux que celles des autres.

En fait, il dit que, de nos jours, les fonctions de hachages cryptographiques dédiées au hachage des mot de passe ne sont plus les mêmes que celles utilisées pour, entre autre, l'intégrité des données (comme SHA), notamment parce que les secondes ont pour but d'être le plus rapide possible tandis que les premières peuvent (et même doivent) être suffisamment lente pour gêner une recherche exhaustive. Et donc, une recherche sérieuse de 5 minutes sur Wikipédia aurait donné une liste de fonctions adéquates (genre bcrypt ou Scrypt), prenant en compte nativement un sel suffisamment long (qui empêche les attaques de type table arc-en-ciel) et des paramètres comme un nombre d'itération qui vont allonger le temps de calcul de la fonction (qui empêche donc des attaques par force brute, y compris sur des petits dictionnaires). Voilà (j'ai eu la flemme de wikipediser ce paragraphe mais ça aurait été cool) !

on demande d'avoir dans la bibliotheque standard, une operation vector::erase_at(size_t idx)

Je vais me répéter mais cette opération ne sert à rien ! Toute la bibliothèque standard fonctionne avec des itérateurs et donc il est logique d'avoir un erase à base d'itérateurs et pas à base d'indice. Autre avantage, ça permet d'avoir une API unifiée pour tous les conteneurs (dont la plupart n'ont pas le concept d'indice, ou alors pas avec un accès aléatoire). Je veux bien que tu me cites un cas pratique de l'utilisation d'une telle fonction avec un exemple suffisamment long pour être pertinent.

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.

Ce n'est pas 0.01% mais bien plus puisqu'en C++, les struct et les class, c'est la même chose (à la différence que dans une struct, la visibilité par défaut est publique tandis que dans une class, la visibilité par défaut est privée). Donc, toutes les structures issues de bibliothèques C (donc utilisables en C++) sont concernées. Or, en C, pas de vtable. Il est donc parfaitement impensable d'avoir comme comportement par défaut que tout est virtuel et qu'on dit ce qui ne l'est pas puisque ça briserait complètement la compatibilité avec le C.

Et pour les cas où il faut un destructeur virtuel, -Wdelete-non-virtual-dtor est là pour émettre un message d'erreur si on a oublié.

De renvoyer un bool et d'avoir un std::vector<std::string>const& en entrée?

Je pense que dans ce cas là, on utiliserait plutôt des std::string_view (qui ont juste un pointeur et une taille, donc pas d'allocation) plutôt que des std::string. Malheureusement, il n'y a pas d'équivalent pour les tableaux.

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

Comme ici par exemple, où je t'ai donné une réponse technique qu'on peut retrouver là ou encore là. Bref, je n'ai pas donné mon opinion, j'ai juste relaté le pourquoi du comment en relayant l'explication quasi-officielle. Et pourtant, cette réponse est à (+1/-2). Tu crois vraiment que je vais continuer pour me prendre des (+1/-2) et au passage m'entendre dire dans la suite des commentaires qu'en fait, ça devrait être simple. Ben non, j'arrête là et tant pis.

Pourquoi es-tu si sensible ?

Parce que je deviens vieux et irascible beaucoup plus facilement.

Que les commentaires de cette dépêche ne te plaise pas, c'est pas grave. Il y a toute une série de dépêche et c'est le langage qui a le plus de journaux. Tu aura pleins d'occasion de discuter de sujets qui te plaisent plus en restant autour de ton langage.

Parce que tu crois vraiment que le fait de voir débouler sur un journal ou une news qui parle de C++ tout un tas de gens qui viennent t'expliquer que Rust/Go/whatever c'est vachement mieux et que t'as rien compris si tu utilises encore C++, ça incite à faire des journaux ou des news sur C++ ? Et bien non, je me dis que j'ai mieux à faire ailleurs, que ça serait une perte de temps.

Maintenant, que tu n'aime pas Rust, c'est ton droit le plus complet.

Ce n'est pas que j'aime ou que je n'aime pas, je m'en fous.

Par contre, sortir des attaques ad hominem comme dans tes autres commentaires et pré-supposer que tes interlocuteurs sont des billes en C++, c'est un manque de courtoisie des plus élémentaires.

Je ne suppose rien, je lis des choses qui sont inexactes et qui servent de base à des dénigrements contre C++. J'en corrige certaines mais je n'ai malheureusement pas le temps pour faire une passe complète. Et quand je lis autant d'approximations, je me dis que les auteurs ne doivent pas être de fin connaisseurs de C++ et qu'ils feraient mieux de ne rien dire. Est-ce qu'exiger qu'on se renseigne un minimum avant de sortir des âneries, c'est devenu un prérequis trop important, même sur linuxfr ?

Je suis peut-être exigeant là-dessus, mais entre vec.erase(vec.begin() + 32); et vec.delete_at(32), je trouve le second bien plus lisible. Et je trouve d'autant plus dommage que le second ne soit pas dans la stdlib au vu de sa facilité d'implémentation.

Sauf que c'est complètement inutile parce que, par exemple, tout un tas d'algorithme générique renvoie des itérateurs (ou des couples d'itérateurs pour marquer le début et la fin d'un intervalle) genre std::find et donc, si tu veux effacer ces éléments, tu es bien content d'avoir erase et ton delete_at serait parfaitement inutile.

De ce que je vois, c'est une “optional technical specification”.

Tu vois mal, c'est marqué en haut dans un cadre avec un gros I devant: «Merged into ISO C++. The functionality described on this page was merged into the mainline ISO C++ standard as of 3/2016; see the filesystem library (since C++17)» avec un lien direct vers la bibliothèque de C++17.

Le comparer à Rust est assez logique puisqu'il se pose en C++-killer, même si ça peu peut être fatiguer.

Voilà, tout est dit, merci.

Pour reprendre tes mots, arrête de venir nous pomper l'air et fait un thread pour mettre en avant ce que nous aimons dans le C++.

Je ne suis pas un VRP de C++, je n'oblige personne à croire que c'est le langage parfait. Je fais des journaux de temps en temps pour ceux que ça intéresse et basta.

Plusieurs personnes ont fait des commentaires sur la complexité du C++ et disent pourtant travailler avec tous les jours.

Oui, mais plusieurs personnes ont fait des commentaires sans vraiment savoir de quoi elles parlaient. Juste des on-dit, des trucs qui datent de plus de 10 ans, etc. C'est saoulant, vraiment. Et surtout, c'est systématique sur les dépêches ou les journaux traitant de C++. Tu pourras refaire l'historique, mais quasiment à chaque fois, il y a quelqu'un pour venir nous parler de Rust. J'ai envie dire : faites des dépêches sur Rust pour parler de Rust, et arrêtez de venir pour pomper l'air pour nous expliquer que C++ c'est de la merde. Chacun est quand même libre d'utiliser le langage qu'il veut. Moi je vis très bien avec C++, ça me va et ce n'est pas les pseudos-arguments des détracteurs qui vont me convaincre. Oui C++ a des défauts, quel langage n'en a pas ? Si le langage parfait existait, ça se saurait depuis longtemps. Et ces défauts, ils me vont bien, je considère même que certains sont des avantages ! Bref, le dénigrement systématique de C++, surtout par des gens qui ne le pratiquent pas, ça me gonfle.

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

Absolument rien n'est basique dans ton exemple. L'existence de liens symboliques et durs fait que ton #pragma once peut te péter à la gueule sans crier gare, sans parler de deux fichiers identiques qui seraient dans deux endroits différents. Bref, si ce n'est pas standardisé, c'est que ces problèmes ne pourront sans doute jamais être résolus de manière sûre. D'autant plus que s'il y a des include guard, les compilateurs sont suffisamment intelligents pour ne pas les réinclure dans les bons cas.

Je me réponds à moi-même pour signaler que j'ai oublié le mot «langue» dans la dernière phrase : «les mauvaises langues diront…»

Finalement, en lisant tous ces commentaires, on se rend compte que C++, c'est ceux qui en mangent le moins qui en parlent le plus. Les mauvaises diront sans doute que les autres sont en train de coder en C++ parce que ça prend plus de temps que dans d'autres langages.

A bon? Et ça c'est quoi alors:

Comme son nom l'indique, c'est l'ABI C++ pour l'architecture Itanium. Et pas l'ABI C++ pour n'importe quelle archi. Il y a aussi celle pour ARM et on pourrait continuer la liste.

C non plus n'as pas d'ABI.

Tout à fait, mais c'est quand même moins pire que pour le C++ de mon point de vue.

ABI des smart pointers n'est pas définie ; donc l'interopérabilité du code n'est garantie que pour des libs headers-only.

Aucune ABI n'est définie pour C++. Et l'ABI est différente suivant les compilateurs (même si Clang et GCC sont alignés) et même dans l'histoire d'un même compilateur (GCC a changé d'ABI C++ plusieurs fois au cours de son histoire, et je ne parle même pas de MSVC). Et en fait, quand tu as une bibliothèque header-only, tu es sûr que ça va marcher partout sans problème d'ABI justement puisque tout est recompilé à chaque fois. Tandis que ta bibliothèque, il faut qu'elle soit compilé quasiment avec la même version de compilateur (notamment sous Windows) que ton programme si tu veux que ça fonctionne sans problème.

on pense à introduire une fonction pour enlever un élément d'un vecteur avant le générateur de gaussiennes.

Un truc comme vector::erase qui existe depuis 98 ?

Parce que ça implique de maintenir plein de choses dans le langage juste pour conserver cette compatibilité, ce qui freine l'évolution du standard.

C'est un choix. Que ce choix soit critiquable, OK. Mais ce choix est le résultat d'un consensus : les gens qui font du C++ sérieusement préfèrent avoir une compatibilité. Même s'il la casse quand même quand c'est nécessaire. Personne ne t'oblige à l'utiliser.

En C++, on a toujours pas de librairies pour le système de fichiers.

Si justement, on en a une maintenant. C'est la même que celle de Boost. Et croire que gérer un système de fichier, c'est facile, c'est se tromper lourdement. Parce que C++ étant compatible avec C, et C étant à la base des systèmes d'exploitation, il faut être compatible avec toutes les bizarreries. Comme par exemple le fait que sous Unix, les noms de fichiers soit des char * mais sous Windows des wchar_t *. Juste ça, ça fout le merdier pour faire un code portable. Avec un langage neuf, tu peux te permettre de cacher ça et de faire des conversions. Mais en C++ où tu t'attends à de la performance, tu dois en tenir compte et faire avec.

Et pour ça, C++ ne part pas gagnant.

Sauf que C++ ne part pas, il est déjà très bien installé et n'est pas près de bouger. Des projets C++ se créent tous les jours.

En fait, on est passé d'un contrôle fort à un contrôle semi-fort. L'ICANN ne vit pas sa vie complètement indépendamment des US, les US sont encore très impliqués, ne serait-ce que par le fait d'héberger quelques serveurs racines de DNS. La FAQ a beau indiquer que l'ICANN ne gère que des choses techniques, le fait même de devoir le préciser fait qu'il y a bien des décisions politiques à prendre et que les US ont gardé un pied dans la porte de manière à pouvoir intervenir au cas où. Ils défendent leurs intérêts (en particulier économiques). En fait, l'émancipation est toute relative et tente d'éloigner tout ce qui ressemble à un gouvernement (y compris l'ONU), tout en laissant une forte influence américaine (même si elle ne passe pas par son gouvernement forcément). D'ailleurs, le siège restera en Californie. Bref, un beau symbole mais en pratique, je demande à voir tellement les signaux sont contradictoires.

Il me semble, mais je peux me tromper que si tu utilises babel french, il n'y a pas besoin d'ajouter des espaces, LaTeX le fait tout seul (il faut peut-être le package xspace mais pas sûr). Moi, j'écrirais comme ça :

foo «bar» egg


En France, je crois qu'il faut être habilité pour délivrer un diplôme. Vu la tête de l'image mise en lien, on pourrait très bien t'accuser de vouloir escroquer les gens en leur délivrant de faux diplômes. Je crois que tu devrais changer le nom et appeler ça autrement.

D'autre part, les Boliviens seront ravis d'apprendre qu'ils sont en voie de développement…

Ouais, et il aura écrit plein de bouquins en plus pour nous en parler:

• La vraie crise arrive, 2018
• Devant nous, le chaos, 2025
• Et si on rebootait le monde, 2037

Que penser alors de std::optional qui peut renvoyer une exception ? :P