rewind a écrit 3443 commentaires

J'ai jamais osé mettre mes «productions» sur un site. À un moment, elles étaient en ligne mais elles ne sont pas restées très longtemps.

C'est malin ! Je viens de passer ma journée à lire des mods ! Malheureusement, pas avec OpenMPT. Mais grâce à cette news, et en particulier la page wikipedia sur les trackers, j'ai découvert qu'il existait un clone de FastTracker 2. Ça compile nickel sous Linux et le résultat est simplement bluffant ! D'après ce que j'ai compris, l'auteur a pris les sources originales en Pascal et assembleur et les a porté en C/SDL2. L'ensemble n'est pas libre, puisque les assets sont sous CC-BY-NC-SA. Mais quand même, ça me replonge une petite vingtaine d'année en arrière. Du coup, j'ai fait de l'archéologie dans mon grenier et j'ai ressorti plein de vieux CD gravés à cette époque là et sur lesquels j'avais toute une collection de xm, s3m et autre mod. Je suis aussi allé faire un tour sur modarchive et sur scene.org pour en chercher quelques autres. Bref, ça fait du bien d'entendre à nouveau Necros, Skaven, Purple Motion, MaF, Zodiak, Keih303, etc !

Personnellement, j'adore les trackers, et je me demande pourquoi ils n'ont pas plus percé que ça. Moi qui n'ai aucune formation musicale (hormis ce qu'on apprends au collège), je pouvais tâtonner et sortir des trucs pas trop mal. Après, pour faire des choses évoluées, il fallait des années d'expérience, mais comme pour tout art. Quand je vois que, de nos jours, il faut un matériel de dingue pour faire de la MAO, j'ai l'impression qu'un tracker demandait (et demande toujours ?) beaucoup moins de ressources (FastTracker2 tournait sur un 486 DX2 à 66MHz !). Vivent les trackers !

c'est ce que j'adore dans les pro-copyleft qui me bassinent avec le "bien commun" du copyleft face à la fermeture du copyfree : le copyleft est en fait utilisé pour verrouiller, sur le produit publicitaire afin de vendre du proprio, ha ha

Prenons un exemple. Une entreprise A a un produit P en copyleft, et un produit P' qui est P avec des fonctionnalités propriétaires. Une entreprise B forke P et commence à ajouter des fonctionnalités pour fabriquer P". Un client C de B achète P". La seule différence avec un client de A, c'est qu'il a accès à l'ensemble des sources de P" et qu'il n'a pas accès aux fonctionnalités de P'. Il peut divulguer les sources de P", la licence l'y autorise, mais il peut aussi les garder pour lui. Admettons qu'il les garde pour lui parce que ça lui coûte de les mettre à disposition et qu'il n'a ni le temps ni l'argent pour ça. Dans tout ça, A n'a pas accès à P". Dans ce scénario, quelle différence, du point de vue de A, avec du copyfree ? Aucun.

Conclusion : le monde n'est toujours pas binaire avec les gentils copyfree et les méchants copyleft.

On ne dit plus static if, on dit if constexpr. Le vocabulaire a évolué pendant la normalisation. Et comme constexpr concerne tout ce qui est calculé à la compilation, le comité a trouvé plus logique de dire if constexpr (if calculé à la compilation).

Avoir une opinion, c'est quelque chose. Défendre une opinion auprès des lecteurs, c'est autre chose. Et interpréter l'actualité, présenter les faits de manière partisane, ou pondre des éditos fallacieux, c'est encore différent. Quand la défense d'une opinion passe par des pratiques de manipulation, de rhétorique douteuse, voire de mensonge flagrant, c'est problématique (et ça veut aussi dire beaucoup sur les bases rationnelles de cette opinion).

Mais c'est dingue ! La presse a toujours défendu des opinions, c'est même son rôle que de débattre des idées, de confronter des points de vue, de donner des prismes de lecture. Si tu veux des faits rationnels et neutre, tu lis une encyclopédie pas un journal.

En quoi est-ce dérangeant que la presse ait une opinion ? Ce qui me gêne, ce n'est pas qu'elle ait une opinion, c'est que la plupart des grands journaux (et en particulier ceux qui sont détenus par les dits milliardaires) ont la même opinion, à quelques nuances près.

Le mieux serait de créer un chapitre

D'accord. Je pense que ce sera plus propre.

Un petit TieBreak ?

Heu… je ne joue pas au tennis ? J'ai eu du mal à le trouver, je ne savais pas qu'il s'appelait comme ça ce machin. Mais OK ! Je t'envoie un mail et on organise un truc.

Microsoft s'est déjà pris une belle amende par le passé et a été obligé de proposé en Europe le choix entre plusieurs navigateurs (vers 2010 de mémoire).

Ce n'était pas les navigateurs le problème mais les lecteurs de fichiers audio/vidéo. Et ils avaient été obligé de sortir une version sans le lecteur par défaut de Windows. Ce sont les versions estampillés N. Et donc, comme on voit que le nom de la version identifie bien le problème, on peut se douter que les gens se ruent dessus… ou pas.

Un tout petit résumé de l'affaire

À la fin de ce fichier, les ensembles N,Z,Q et C sont construits avec leurs principales structures : ordre, anneau, groupe, corps.

Donc, si je comprends bien, tu voudrais mettre les définitions/propriétés liées aux langages à la fin de ce fichier. C'est bien ça ? Et pour les machines de Turing, à la suite ?

D'autre part, dans mazhe.pdf, je n'ai pas trouvé la définition d'un monoïde (il y a juste le lemme 6.19 qui parle de sous-monoïde et quelques autres trucs mais jamais de définition formelle). Or, l'ensemble des mots sur un vocabulaire muni du produit (concaténation) forme un monoïde (non-commutatif).

Enfin, en parcourant ton site, je m'aperçois qu'on travaille à 300m l'un de l'autre, ça vaudrait sans doute le coup qu'on se voit IRL pour discuter de tout ça ;)

Ou plus modestement, rédiger la définition d'une machine de Turing et donner deux exemples serait déjà pas mal.

Si on reste dans l'esprit du livre, on ne peut pas se contenter de ça. Parce que parler de machine de Turing sans parler de langage, ça n'a pas de sens. Donc, il faut définir ce qu'est un langage, et donc définir ce qu'est un alphabet, un mot. Cependant, les langages peuvent partir de la théorie des ensembles (puisque ce sont eux-mêmes des ensembles et que beaucoup de notions sont identiques).

Si j'ai du temps, j'essaierai de contribuer sur cet aspect. Je fais un cours de Théorie des Langages donc j'ai déjà quelques définitions sous la main.

C est là depuis longtemps et occupe une place qu'aucun autre langage ne peut prendre. C est la lingua franca des langages de programmation puisque quasiment tous les autres peuvent appeler une fonction C alors que l'inverse est très souvent faux. C a un écosystème énorme comparé à Go ou Rust. C est omniprésent dans l'embarqué et le premier compilateur présent sur une nouvelle architecture est quasiment toujours un compilateur C. Bref, vouloir prendre la place de C, c'est un doux rêve. Ce qui ne veut pas dire que ces langages (Go et Rust) n'ont pas un intérêt propre.

le fond est justement l'usage de mensonges

Non, ça c'est la forme.

En 1936, quand les syndicats proposaient les congés payés, il y avait déjà des Zenitram pour expliquer à quel point c'était complètement démagogique, et que les syndicats n'aidaient pas les salariés parce qu'ils allaient couler les entreprises. Imaginez-vous, être payé à ne rien faire, vraiment ils voulaient la ruine du pays ces saloperies de syndicats. Et pourtant, l'histoire leur a donné raison.

On pourrait multiplier ce genre d'exemples tout au long de l'histoire. Tu ne fais qu'un mauvais remake d'une pièce qui a déjà été joué des dizaines de fois. Mais les faits sont là, toi qui adore te référer à la vérité, jamais on n'a vu une avancée sociale venir des patrons, ce sont toujours les syndicats qui ont obtenu toutes les avancées sociales à force de lutte acharnée. La Sécurité Sociale, par exemple, ça vient d'un ministre communiste de De Gaulle qui était ouvrier auparavant, ça n'est pas venu du Gattaz de l'époque (ou plutôt du Roux de Bézieux de l'époque). Et chaque fois que les syndicats sont en difficulté, certaines conquêtes sociales disparaissent ou sont rabotées. C'est ce qu'il se passe en ce moment. Mais on trouvera toujours un Zenitram pour expliquer que c'est la faute des syndicats qui sont beaucoup trop exigeants, ce n'est jamais la faute du gouvernement aux ordres du patronat et qui écrit les lois de régression sociale. Bref, du déjà vu, rien de nouveau.

Tant de mots pour nous confirmer ton anti-syndicalisme primaire, mais pas un mot pour dénoncer les agissements des patrons d'ALTRAN qui ont l'air d'être des récidivistes. C'est triste.

Dans ce cas, tu es comme dans le dernier cas que j'ai cité du shared_ptr, tu ne sais pas si tu vas conserver le paramètre ou pas, donc tu passes une référence constante et tu fais la copie seulement si besoin. Donc on est bien d'accord et c'est très logique en fait.

Non, ce n'est pas inversé. Je vais prendre un exemple avec std::string pour que ce soit plus clair. L'hypothèse de départ, c'est qu'on veut conserver la chaîne de caractères passé en paramètre (sinon, pas besoin de se poser la question, voir plus bas). Le cas le plus fréquent, c'est un constructeur, mais ça pourrait être n'importe quelle fonction.

struct Toto {
  Toto(std::string s) : str(std::move(s)) { }
  std::string str;
};

struct Titi {
  Titi(const std::string& s) : str(s) { }
  std::string str;
};

int main() {
  std::string str1("str1");

  Toto toto1(str1); // (a)
  Toto toto2("str2"); // (b)

  Titi titi1(str1); // (c)
  Titi titi2("str2"); // (d)
}

En (a), il y a une copie qui est faite au moment de l'appel, mais dans le constructeur, il n'y a pas de copie, juste un déplacement (ce qui revient à déplacer le pointeur). En (b), il n'y a pas de copie, la chaîne est construite dans le paramètre qui est ensuite déplacé dans la variable membre. En (c), il y a un passage de référence au moment de l'appel, mais il y a une copie dans le constructeur. En (d), il y a une création d'une chaîne sur la pile, puis il y a une copie dans le constructeur. Au final, en passant par valeur, on s'évite une copie si on passe un littéral, alors qu'en passant par référence, on a une copie superflue. C'est pour ça que depuis C++11 (depuis qu'on a la sémantique de déplacement), il est conseillé de passer ce genre de paramètre par valeur, et plus par référence.

Si on n'a pas besoin de conserver le paramètre, alors il faut passer le paramètre par référence constante. Mais ce cas était déjà géré avant C++11.

Dans le cas d'un std::shared_ptr<T>, on peut tenir le même genre de raisonnement, mais il y a une subtilité en plus qui est qu'on a en fait deux objets : le pointeur intelligent en lui-même (std::shared_ptr), et l'objet pointé (de type T). Comme le précise Herb Sutter dans l'article que j'ai lié un peu plus haut, si on n'a besoin que de l'objet pointé, on doit passer soit une référence sur un T, soit un pointeur sur un T parce que ça rend la fonction plus générique en ce sens qu'on ne la restreint pas à une seule politique de gestion mémoire. Si on a besoin de partager le pointeur, alors on passe un shared_ptr<T> par copie (pour la même raison que pour le std::string précédemment). Si on passe un shared_ptr<T> par référence non-constante, c'est qu'on veut modifier le pointeur lui-même et pas l'objet pointé. Et si on le passe par référence constante, c'est qu'on ne sait pas si on va faire une copie ou pas, mais ce cas est extrêmement rare et c'est précisément celui qui est donné en exemple dans le post initial.

Changez rien, les gars.

Effectivement, il n'y a rien à changer. C++ permet une gestion très fine de la mémoire et des passages de paramètres (par valeur ou par référence, on a le choix, contrairement à quasiment tous les autres langages), et donc il y a des implications à choisir l'un ou l'autre. Mais ces implications sont très loin des «effets papillons». C'est juste histoire de savoir ce qu'on fait et comment ça se passe. Il y a des gens qui ont besoin de ce genre de subtilités pour avoir des performances, c'est bien qu'il existe un langage qui leur permette de le faire, il s'appelle C++.

Si tu le passes par références pour le stocker tu n'as qu'une seule copie.

Le lien que tu donnes dit explicitement «Shortly, there is no reason to pass by value, unless the goal is to share ownership of an object», ce qui est exactement ce que j'ai dit plus haut : «Soit on a besoin d'un partage et dans ce cas là, on passer par valeur.»

Et après, de manière générale, si tu veux stocker un objet, tu as intérêt à le demander par valeur (ça ne concerne pas que les shared_ptr pour le coup) pour éviter des copies justement. Dans le cas du passage par référence, l'objet va être créé puis copié dans la fonction. Dans le cas du passage par valeur, il va y avoir zéro copie, l'objet va être créé puis déplacé directement.

Dans le lien que tu donnes, il y a d'ailleurs une réponse qui pointent vers un post de Herb Sutter qui est accessoirement le président du comité de normalisation et qui donne une réponse très détaillée pour tous les cas de figure.

On peut voir le résultat de la compilation sur godbolt. J'ai mis GCC et Clang, il y a quelques différences. Mais à vue de nez, je ne sais pas s'il y a vraiment beaucoup de différences.

Ceci dit, je trouve bizarre de passer un shared_ptr par référence. Soit on a besoin d'un partage et dans ce cas là, on passer par valeur. Soit on n'a pas besoin d'un partage et là, on déréférence le pointeur et on envoie une référence directe sur l'objet. Une référence sur un shared_ptr, ça nécessite deux déréférencement pour atteindre l'objet, c'est un de trop.

Personne ne t'a jamais empêché de faire un projet en Rust tout seul dans ton coin, et c'est bien comme ça.

J'ai pointé du doigt un argument qui est donné en boucle… et qui n'est pas lié à un raisonnement valide, ce n'est qu'une justification pour ne jamais rien changer, quelqu'en soit les conséquences, peu importe s'il y aurait effectivement mieux à faire.

Ton argument ne prend pas en compte la réalité. Si tu as tout un tas de gens qui programment en C++ depuis très longtemps, c'est-à-dire qui ont atteint un niveau de productivité en C++ qui permet aux entreprises qui les emploie de faire du profit, quel est l'intérêt de les faire changer de langage ? À part perdre du temps, de l'argent à les former pendant des années avant qu'ils atteignent la même productivité, je ne vois pas. C'est un comportement totalement non-rationnel, quand bien même ton super langage serait top-moumoute.

On l'a déjà dit mais C++ a déjà vu passer bon nombre de ces langages révolutionnaires qu'il fallait absolument utiliser tellement ils étaient trop bien et qu'ils allaient remplacer C++. Bizarrement, C++ est toujours là, c'est peut-être, comme on le dit, qu'il n'y a pas que les fonctionnalités remarquables qui comptent, il y a tout le reste.

Et je me fiche complètement de l'argument "ouais mé ton manager y ve pa lol", la question ici s'adresse à des gens intelligents qui comprennent les tenants et aboutissants y compris techniques, pas des managers.

C'est une question éminemment technique ! Pourquoi crois-tu que Google, Apple, Microsoft et tant d'autres investissent autant de temps et d'argent pour faire avancer le standard C++ ? Ce n'est pas une lubie de managers, c'est bien parce qu'il y a un passif technique et qu'ils préfèrent sans doute faire évoluer l'existant (et donc le langage) plutôt que de passer complètement à un autre langage.

Se baser uniquement sur le fait qu'on ait du code dans un langage dans un coin pour justifier que tout ce qu'on fera par la suite sera dans ce même langage

Ton raisonnement ne tient pas debout. Du nouveau code est créé chaque jour, dans tout un tas de langage. Rien n'empêche plein de gens de créer plein de code en Rust, Brainfuck ou autre. S'ils ne le font pas, c'est qu'ils ont leurs raisons. Un langage en remplace un autre quand il atteint une masse critique. Rust en est encore loin, très loin. Ce n'est pas parce qu'un langage est «meilleur» qu'un autre qu'il le remplace auto-magiquement (et je mets des guillemets parce que chacun a une définition de «meilleur»).

Cet interfaçage demande à faire une couche de translation C ou C++98 vers C++11. Hors ces 3 langages sont presque totalement compatibles donc il est assez subtile de s'assurer que l'on ne leak pas du C dans le reste de ton programme. Une méthode C++98 qui te retourne un objet dont les méthodes manipulent des pointeurs nus. Tu va devoir proxifier l'ensemble de l'objet en tenant potentiellement compte de l'overhead que tu introduit (c'est important pour un langage dont l'un des principaux arguments c'est la performance).

Là, tu racontes absolument n'importe quoi. Faire une surcouche C++ d'une bibliothèque en C, ça améliore la sûreté d'utilisation de la bibliothèque en C sans ajouter aucun overhead. Petit exemple, disons que j'ai une bibliothèque C avec des fonctions de ce genre:

struct foo;

struct foo *foo_create(int foo_param);
void foo_delete(struct foo *f);

void foo_do_something(const struct foo *f);

Je fais ma surcouche de la manière suivante:

class Foo {
public:
  Foo(int foo_param)
  : m_f(foo_create(foo_param))
  {
  }

  ~Foo() {
    if (m_f) {
      foo_delete(m_f);
    }
  }

  // j'interdis les copies parce que l'API de base ne permet pas de copier l'objet
  Foo(Foo&) = delete;
  Foo& operator(Foo&) = delete;

  // j'autorise le transfert de propriété
  Foo(Foo&& other)
  : m_f(std::exchange(other.m_f, nullptr))
  {

  }

  Foo& operator=(Foo& other) {
    std::swap(m_f, other.m_f);
  }

  void doSomething() const {
    foo_do_something(m_f);
  }

private:
  foo *m_f;
};

Comme tout va être inliné, je n'ai aucun overhead, et je m'assure que le destructeur fait bien son boulot dans tous les cas. Et du point de vue du programmeur C++, il n'y aucun pointeur venu du C à gérer, c'est totalement transparent.

Au final, il faudrait quoi du coup pour faire changer les mentalités à propos du C++ ?

Et il faut aussi s'excuser de continuer à faire du C++ ? Franchement, C++ a des défauts, personne ne dit le contraire, il a aussi des qualités, il a un écosystème gigantesque, c'est un standard international qui évolue très activement, il a trois compilateurs majeurs, il a une gestion bas niveau de la mémoire (oui, pour certains, c'est un avantage), il a une tétrachiée de bibliothèques disponibles pour tout et son contraire (en incluant les bibliothèques en C puisqu'elles sont quasiment directement utilisables en C++). Il faut quoi de plus ?

Ça m'intéresse d'avoir des avis sur CBC par rapport à GLPK. Il m'a l'air plus compliqué à utiliser (l'API est… rude on va dire).

Pourquoi ne pas conseiller GLPK pour la résolution du programme linéaire ? Gurobi n'est pas libre. Certes il marche franchement mieux mais bon, quitte à faire du libre, autant aller jusqu'au bout. GLPK ne se défend pas si mal que ça.

Pour tester avec des paramètres variés sur des algos génériques, je conseille gf qui s’accompagne d’un petit programme gf_dungeons pour générer des cartes.

Très bon choix ;)

Ceci dit, l'important, ce ne sont pas les algos de base, mais c'est la manière de les utiliser et de les adapter pour que ça rende le jeu unique et je crois que de ce point de vue, pour boohu, c'est une réussite.