rewind a écrit 3425 commentaires

  • [^] # Re: ...

    Posté par  (Mastodon) . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 0.

    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…»

  • # ...

    Posté par  (Mastodon) . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 7.

    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.

  • [^] # Re: Donc pour résumer…

    Posté par  (Mastodon) . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 5.

    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.

  • [^] # Re: Donc pour résumer…

    Posté par  (Mastodon) . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 6.

    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.

  • # Changement de titre

    Posté par  (Mastodon) . En réponse au journal ICANN n'est plus fortement lié aux USA. Évalué à 8.

    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.

  • [^] # Re: autres petites remarques rapides

    Posté par  (Mastodon) . En réponse à la dépêche Le Frido, un livre de mathématique libre pour l’agrégation. Évalué à 3.

    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

  • # Diplôme ?

    Posté par  (Mastodon) . En réponse à la dépêche CatchChallenger version 2. Évalué à 5.

    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…

  • [^] # Re: La solution

    Posté par  (Mastodon) . En réponse au journal "Tant pis, ce seront nos enfants qui paieront". Évalué à 2.

    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
  • [^] # Re: C++ et exceptions

    Posté par  (Mastodon) . En réponse au journal Gestion de l'erreur - C++ - std::optional. Évalué à 4.

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

  • [^] # Re: C++ et exceptions

    Posté par  (Mastodon) . En réponse au journal Gestion de l'erreur - C++ - std::optional. Évalué à 5.

    La librairie standard c++ utilise les exceptions, mais dans certains cas limités, comme une allocation ratée.

    Elle l'utilise aussi dans vector::at (et d'autres du même genre comme string::at) qui est l'équivalent de l'accès indicé (celui avec les accolades) mais avec vérification du domaine. Et il y a les fonctions de conversion genre std::stoi qui peuvent renvoyer des exceptions. Il y a aussi des fonctions liées au système comme std::thead::detach. Et puis, il y a quasiment toutes les fonctions de std::filesystem qui ont deux versions : une avec exception et l'autre avec un code d'erreur.

    Bref, affirmer que la bibliothèque standard utilise les exceptions dans des cas limités est erroné. Elle utilise les exceptions pour les cas exceptionnels, ce qui est la raison d'être des exceptions.

  • [^] # Re: chauve qui peut

    Posté par  (Mastodon) . En réponse au journal "Tant pis, ce seront nos enfants qui paieront". Évalué à 10.

    C'est fondamentalement différent.

    Dans le système par répartition, tu paies les retraites de l'instant n avec une partie de la production de l'instant n (via des cotisations sociales). On considère que c'est la production qui doit payer pour les travailleurs (maladie, vieillesse, chômage). Donc tu n'as à t'occuper que de l'instant n (même si en vrai, tu peux essayer de faire des projections démographiques pour voir si ça va continuer à fonctionner). La cotisation sociale t'ouvre des droits.

    Dans le système par capitalisation, t'as intérêt à serrer les fesses, parce que tu mets de côté à l'instant n pour payer ta retraite à l'instant n + 20 ans (en moyenne). En attendant, ben ça alimente la bulle financière qui peut éclater à tout instant (et en 20 ans, elle éclate quelques fois) et du coup, ça te ruine tout ton pécule régulièrement.

  • # La solution

    Posté par  (Mastodon) . En réponse au journal "Tant pis, ce seront nos enfants qui paieront". Évalué à 8.

    Moi je propose qu'on sacrifie tous les baby-boomers, comme ça ils ne coûteront rien. Et sinon, plus sérieusement, si François Lenglet avait des choses intéressantes à dire, ça se saurait depuis le temps. Beaucoup de ses bouquins partagent le même genre de titre racoleur :

    • La crise des années 30 est devant nous, 2007
    • Qui va payer la crise ?, 2012
    • Tant pis, nos enfants paieront, 2016
  • [^] # Re: chauve qui peut

    Posté par  (Mastodon) . En réponse au journal "Tant pis, ce seront nos enfants qui paieront". Évalué à 9.

    euh ouais, non, moi je trouve pas ca normal que ma gamine paie pour moi. Je met mes cacahouètes de cote, pas envie d'être un boulet pour elle, ca marche pas dans ce sens la…

    Indices : cotisation sociale, retraite par répartition

  • [^] # Re: Ouai bah tant pis.

    Posté par  (Mastodon) . En réponse au journal Aseprite devient propriétaire. Évalué à 3.

    En fait, ça ne le dérange pas que les gens compilent leur version chez eux. Mais il ne veut pas de redistribution.

  • [^] # Re: Ouai bah tant pis.

    Posté par  (Mastodon) . En réponse au journal Aseprite devient propriétaire. Évalué à 4.

    En fait, en cherchant un peu plus, on comprend un peu mieux le pourquoi du comment dans la FAQ:

    If Aseprite is open source, how is that you are selling it?

    Aseprite started being open source since its very beginning in 2001, and we would like to keep it in that way. You can download its source code, compile it, and use it for your personal purposes. You can make commercial art/assets with it too. The only restriction in Aseprite EULA is that you cannot redistribute Aseprite to third parties.

    In June 2014, when Aseprite v1.0 was released, we enter into this new world of selling open source software. And its lead developer is working full-time on Aseprite since March 2015.

    C'est la dernière phrase qui est importante. Il flippe. Il veut simplement contrôler la redistribution pour pouvoir faire de l'argent. Argument classique, même si complètement erroné, à mon avis.

  • [^] # Re: Manger sa propre nourriture

    Posté par  (Mastodon) . En réponse à la dépêche Le logiciel libre au-delà de x86. Évalué à -4.

    … dit le gars qui développe un soft libre sur un OS non-libre (alors que là, pour le coup, il y a le choix).

  • [^] # Re: Héhé

    Posté par  (Mastodon) . En réponse au journal Microsoft: Powershell libéré. Évalué à 4.

    J'adore ce genre de réponse. Avant on nous vendait systemd comme un sysinit killer qui allait tout mieux faire, bien proprement et qu'on était vraiment des dinosaures à vouloir encore rester avec sysinit. Là, on est passé à un stade où on doit accepter d'avoir les mêmes bugs (parce que c'est un bug) que sysinit. Tout changer pour que rien ne change. D'autant plus que la réponse ne correspond pas à la question. On s'en fout qu'il y ait les mêmes problèmes avec sysinit. On l'a enterré sysinit (ou presque), le problème là il est bien dans systemd.

  • [^] # Re: Une team, un projet, un moteur de jeu libre ( ou pas )

    Posté par  (Mastodon) . En réponse à la dépêche Ouverture du site Libre Games Initiatives. Évalué à 3.

    Personnellement, si je devais choisir un moteur, je prendrais Godot.

    Et pour le reste, ce n'est pas en gérant les derniers gadgets à la mode (les modes passent et un jeu libre a vocation a durer dans le temps) qu'un jeu libre se démarquera mais en réalisant un jeu avec un excellent game design et sur une niche peu exploité par les AAA. Le mauvais choix typique serait de vouloir faire un FPS, marché saturé par des gros titres. Un bon exemple, c'est Wesnoth qui s'est placé sur la stratégie tour par tour.

  • [^] # Re: et vulkan

    Posté par  (Mastodon) . En réponse à la dépêche SDL ou SFML ? Ne choisissez plus, prenez Gamedev Framework (gf). Évalué à 2.

    Tu peux me contacter à l'adresse mail indiquée ici

  • [^] # Re: et vulkan

    Posté par  (Mastodon) . En réponse à la dépêche SDL ou SFML ? Ne choisissez plus, prenez Gamedev Framework (gf). Évalué à 2.

    Houla, il faut que je vois si c'est techniquement possible. J'habite un peu à l'autre bout de la France :)

  • [^] # Re: Tiptop le sexisme

    Posté par  (Mastodon) . En réponse à la dépêche Ouverture du site Libre Games Initiatives. Évalué à -1.

    Ouais, en gros, tu expliques qu'avec ce CD, tu ne fais que perpétuer activement tous les clichés sexistes de nos sociétés. Tu véhicules tous ces clichés en toute connaissance de cause sous prétexte que c'est comme ça. J'avais donc bien compris.

  • [^] # Re: Tiptop le sexisme

    Posté par  (Mastodon) . En réponse à la dépêche Ouverture du site Libre Games Initiatives. Évalué à -6.

    Si jamais un sondage fait proprement dit qu'un certain groupe possède une préférence (et ce de manière significative) mais que tu n'expliques pas de manière « objective », tu vas simplement nier son existence ?

    Tu n'as pas cité ma phrase en entier et notamment la partie la plus importante : du fait de leur sexe. Je ne nie pas qu'un groupe puisse avoir des préférences (heureusement) mais lier ces préférences à leur sexe est une autre chose. Le fait que le groupe interrogé ne contiennent que des filles ne permet absolument pas de dire que les filles, de manière générale, préfèrent ces jeux. Dit autrement, qu'est-ce qui explique qu'une fille, c'est-à-dire un individu avec des chromosomes XX, préfère ces jeux plutôt que d'autres ? Est-ce vraiment le fait qu'elle ait des chromosomes XX ou alors c'est tout autre chose ?

  • [^] # Re: Tiptop le sexisme

    Posté par  (Mastodon) . En réponse à la dépêche Ouverture du site Libre Games Initiatives. Évalué à -4.

    Admettons, il y a eu un sondage : sur combien de personnes ? est-ce que le panel était représentatif ? est-ce que depuis 2011 la situation a évolué ? Mais même si tout était nickel de ce point de vue (ce que je ne crois pas), il n'y a aucune raison objectives que les filles prises dans leur ensemble préfèrent certains jeux à d'autres du fait de leur sexe. Ça n'a aucun sens.

  • [^] # Re: De l’utilité des exceptions.

    Posté par  (Mastodon) . En réponse à la dépêche SDL ou SFML ? Ne choisissez plus, prenez Gamedev Framework (gf). Évalué à 3.

    Une grande partie de l'industrie est passée à des langages plus hauts niveaux, comme Unity+C# (j'ai quand même regardé rapidement et il semble bien que leur API parle d'exceptions, comme ici).

    Deux choses. Premièrement, dire qu'une partie de l'industrie est passée à Unity+C#, c'est un peu trop fort je pense. Il y a probablement autant de jeux sous Linux que de jeux commercialement viable fait avec Unity. En revanche, si on parle en termes de projet à peine commencé, là oui Unity est devant tout le monde. Deuxièmement, d'aucuns diraient que le C# de Unity, c'est très différent du C#, et qu'à part cette Exception, il n'y a pas d'autres traces. Ce qui pourrait s'expliquer par le fait que le cœur de Unity est écrit en C++ et que le C# ne sert qu'à faire du scripting et que les deux systèmes d'exception ne doivent pas collaborer très bien.

  • [^] # Re: De l’utilité des exceptions.

    Posté par  (Mastodon) . En réponse à la dépêche SDL ou SFML ? Ne choisissez plus, prenez Gamedev Framework (gf). Évalué à 4.

    Depuis 1989, date du papier, on a un peu plus d'expérience sur l'utilisation des exceptions. Et parmi toutes les entreprises qui utilisent C++, de grands pans refusent les exceptions dont toute l'industrie des jeux vidéos (puisqu'on en parle), et des petites PME du genre Google qui doit avoir une des plus grosses bases de code en C++ au monde.