rewind a écrit 3425 commentaires

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.

Si on consacre 5% de son budget pour 1% des élèves (c'est un peu le principe des ENS), ça permet de doubler leur niveau en sortie et ils pourront servir de « locomotive intellectuelle » (pour doper l'innovation, la recherche, former des disciples, …).

C'est la théorie du ruissellement intellectuel ?

Je n'ai pas de solution toute faite à ce problème: les étudiants qui passent les premières années à la fac sont assurément capables, mais ne bénéficieront pas de ces moyens colossaux mis en écoles d'ingés.
Mais la sélection à l'entrée, apparemment ça coince, parce que ce serait "trop violent".

Il y en a une de sélection à l'entrée de l'université, ça s'appelle le bac. Le bac est le premier diplôme universitaire et donne droit à s'inscrire à l'université. Ce n'est pas parce que les politiques ont totalement dévoyé ce diplôme à force de vouloir un taux de réussite surréaliste qu'il faut jeter le bébé avec l'eau du bain. Dans les années 70-80, il y avait un taux de réussite entre 60 et 70%, ça me semble plutôt honnête (avec des programmes nettement plus difficiles qu'aujourd'hui mais 20 à 30% d'une classe d'âge qui avait son bac, contre plus de 70% aujourd'hui).

Bravo, belle illustration du propos du journal ! Je n'aurais jamais pu faire aussi bien, j'aurais craqué avant la fin.

On va retourner le problème dans l'autre sens : est-ce que toi ça te dérange ? Apparemment pas puisque tu dis «certains» impliquant que tu ne t'y inclues pas. Alors pourquoi tu fais ce commentaire ? Qu'est-ce que ça te coûte de ne rien dire plutôt que de défendre des gens qui n'existent pas pour l'instant puisque personne ne s'est déclaré choqué par ce titre somme toute complètement banal ? Qu'est-ce que ça change d'aller lire un autre journal ou un autre code source ?

Il y a plein de choses à dire sur cette augmentation des frais de scolarité, mais bon quand-même, il faut raison garder.

On peut quand même être contre le principe même des frais d'inscriptions, qu'ils soient à 100, 1000 ou 10000 euros. Surtout que vu la hausse, ce n'est qu'un début, ça va augmenter pour s'aligner sur la «concurrence» internationale.

Je ne cautionne pas le modèle américain, mais je pense néanmoins que l'investissement est toujours rentable pour les centraliens, même s'il l'est bien moins qu'avant.

Le hic, c'est qu'on commence par ceux à qui «ça ne pose pas de problème» (et encore…) et ensuite, on va généraliser à tout le monde, et ça va poser pleins de problèmes. Le projet de hausser les frais d'inscription n'est pas un fantasme de gauchiste anti-macron, c'est une des propositions très concrète du fameux rapport Cap22 qui a été remis récemment au gouvernement.

libéralisme = moins d'état

C'est une caricature, pas une définition. De plus, les libéraux ne veulent pas abolir l'État, même les plus acharnés reconnaissent que l'État doit assurer des fonctions de police, de justice et de défense. Mais la chapelle libérale majoritaire de nos jours, c'est l'ordolibéralisme, qui n'interdit pas du tout que l'État puisse être garant de prêt puisque ça n'empêche pas une concurrence libre et non faussée entre les banques. Dit autrement, le marché des prêts étudiants reste concurrentiel et l'honneur est sauf pour le dogme.

Dans l'absolu, je ne suis pas contre payer pour ses études, car le fait de payer implique le consommateur du service.

Non, un étudiant est un usager du service, pas un consommateur, pas un client. D'ailleurs, il ne paie pas pour le service (sinon, il paierait bien plus cher), mais pour s'inscrire. Si on fait payer des milliers d'euros, les usagers vont vraiment se transformer en consommateur/client, mais il ne faudra pas s'étonner des effets de bords.

Houla, que de confusion…

C'est très bien, ça incitera les étudiants à aller à la fac.

Non, parce que cette augmentation des frais d'inscription, c'est également ce qui attends les universités. Depuis la loi LRU, elles ont l'autonomie dans la gestion de la pénurie, et une des seules solutions pour compenser cette pénurie de moyens, c'est d'augmenter les frais d'inscription. On va y venir assez vite, malheureusement.

Les écoles d'ingé sont un vestige de Napoléon qui n'a plus de raison d'être aujourd'hui.

Ça dépend lesquelles. Certaines écoles avaient pour mission de former techniquement les hauts fonctionnaires (je ne parle pas de l'ENA) de manière à ce qu'ils assurent un service public de grande qualité : Ponts et Chaussée, Centrale, Mines, Polytechnique, ENS, etc. De nos jours, on délègue tout au privé donc ça a moins de sens. Mais du coup, on continue de former des ingénieurs de très bonne qualité.

D'ailleurs ça n'existe quasiment pas à l'étranger et c'est incompatible avec le système LMD européen en place depuis plus de 10 ans.

Les écoles délivrent un BAC+5 qui est l'équivalent d'un master. Le seul problème pour nos dirigeants du CAC40 issues de ces grandes écoles, c'est qu'à l'étranger, les dirigeants ont souvent un doctorat, ça pose problème quand ils essaient de se vendre en dehors de la France. C'est pour ça que le ministère a dans ses cartons une sorte de doctorat en VAE qu'on pourrait donner à n'importe qui.

En plus, ça coûte cher

Alignons pas le bas, la bonne idée ! Il faudrait plutôt que des moyens similaires soient mis dans l'université et ça serait top.

ça favorise la dispersion, avec les conséquences que l'on connait sur les classements internationaux des universités.

Alors ça, on s'en fout complètement. Ces classements sont tous biaisés et ne reflètent absolument pas la qualité des formations. Les auteurs du classement de Shangai (puisque c'est le plus connu) reconnaissent eux-mêmes toutes les limites de leur approche.

un prêt étudiant à des taux usuriers et irrévocable en cas de faillite personnelle.

Un adhérent de LREM a trouvé encore mieux que ça ! Il proposait que les prêts soient garantis par l'État. Comme ça, en cas de faillite, les banques retrouvent leur argent. Le document était un bijou d'ultra-libéralisme avec sa dose d'anti-syndicalisme comme il faut.

D'un autre côté, on parle de centraliens. S'ils doivent faire un emprunt, ils devraient pouvoir le rembourser assez vite avec un brut moyen de 52 000 € par an.

C'est exactement l'argument employé aux États-Unis et ailleurs pour justifier tous les frais d'inscription. Et on voit le résultat : la dette étudiante aux États-Unis est abyssale et va péter à la gueule de tout le monde façon subprime.

Quand bien même cet argument serait vérifié, ça avantage qui de devoir rembourser un prêt dès les études finies ? Je veux dire, globalement et socialement parlant, il n'y a que les banques qui y trouvent leur compte. Toujours dans cette hypothèse farfelue, ces gens pourraient contracter un prêt pour s'acheter un logement, une voiture ou que sais-je, mais vu leur niveau d'endettement au départ, ils se retrouvent à devoir attendre avant de pouvoir acquérir un bien onéreux.

Et du coup, est-il plus facile de programmer en gObject (GTK+) qu'en C++ (Qt) ?

Il y a deux questions là. S'il s'agit de comparer uniquement gObject et C++, alors C++ est clairement gagnant, puisqu'en gObject, il faut faire à la main ce qui est fait automatiquement par le compilateur en C++, à savoir le polymorphisme via les vtables. S'il s'agit de comparer GTK+ à Qt, c'est une affaire de goûts et de couleurs. Il existe même Gtkmm qui permet d'utiliser GTK+ en C++.

Ça a l'air d'être un problème de packaging, il faut le signaler à Debian ;)

Je ne connais pas par coeur Go mais son modèle ressemble également à celui d'Erlang. Pourquoi dire que ce sont de vieux modèles de programmation parallèle?

Le modèle de Go est un dérivé de CSP qui date des années 70. Ce modèle a été étudié en continu depuis et est extrêmement bien connu.

Qu'est-ce qui est plus moderne? Aurais-tu des exemples?

Le vol de travail par exemple est un modèle un peu plus récent.

Avoir une garantie de sûreté d'un code threadé avec Rust est un leurre puissant mais qui, au fond, ne sert pas à grand chose. Parce que personne ne devrait lancer un thread directement, tout le monde devrait utiliser un modèle de programmation parallèle. Par exemple, en Go, il y a un modèle de programmation parallèle, certes vieux, certes plein de limites, mais qui fonctionnent et offre des garanties sans avoir à manipuler le moindre thread. Autre exemple, MapReduce qui est un modèle de programmation parallèle (qui ne résout pas tous les problèmes, mais if non plus ne résout pas tous les problèmes séquentiels) où l'utilisateur final n'a pas à se soucie de l'ordonnancement, ça marche. On pourrait aussi parler des futures, du vol de travail, ou de tout un tas d'autres modèles déjà existants et éprouvés et dont on sait comment ça se programme correctement avec des threads.

Le seul qui doit faire attention, c'est celui qui va implémenter le modèle de programmation parallèle par dessus les threads, mais a priori lui il sait ce qu'il fait, il peut tout vérifier de son côté (soit directement, soit à l'aide d'un outil, soit parce que comme Rust le compilateur va lui dire que c'est bon). Mais ça fait quand même peu de monde qui a une réelle utilité de cet outil de mon point de vue.

Pour un premier langage, Python ou Go me semblent plus pertinents

Tu viens de péter mon trollomètre. Dans les universités, les discussions sur les langages de programmation à apprendre à des débutants ressemblent à ça : c'est violent et ça n'avance pas parce que chacun a ses idées préconçues et ses préférences.

Après, ça dépend ce qu'on veut faire avec un premier langage. Si par exemple un des objectifs est d'apprendre les types (types simples puis structurés), je ne suis pas sûr qu'un langage à typage implicite comme Python soit une bonne idée. Choisir le bon type, c'est aussi de la programmation, et ça se fait beaucoup plus facilement si le type est explicite. Après, si on ne s'intéresse qu'aux structures de contrôle, tous les langages partagent à peu près les mêmes à un chouia près.

Mon avis, c'est que le C++ est un bon langage pour débuter. Évidemment, pas tout C++, juste ce qu'il faut pour comprendre les concepts de base. Parmi les avantages que je vois : les entrées/sorties sont «faciles» (même si la syntaxe peut paraître bizarre), et quand on commence, c'est un frein en moins ; les fonctions permettent de passer les arguments par valeur ou par référence au choix, et c'est un des rares langages qui le permettent (avec la famille Pascal/Ada) ; le langage est suffisamment peu verbeux au démarrage (je dis ça parce que dans mon université, on utilise Java comme premier langage et il y a tout un tas de trucs que les étudiants écrivent sans les comprendre «public class Toto { public static …»). Sans même utiliser la bibliothèque standard (sauf les entrées/sorties), on peut faire un cours pour débutant sans aucun problème et voir tout ce qu'il y a à voir pour commencer (structures de contrôle, types, fonctions).

Qu'il y ait des petits studios qui utilisent Rust, oui, pourquoi pas. On peut aussi en trouver qui le font en D, en Go, ou en Pascal je suis sûr. Ça n'est pas vraiment un indicateur. Tous les gros studios restent encore en C++, ça c'est un indicateur.

Sinon, que veut dire le modèle mémoire va venir se mettre en travers des développeurs ?

Qu'on ne peut pas faire de trucs «sales» en Rust. Je mets «sale» entre guillemet parce que ce n'est pas vraiment le bon terme. Je dirais plutôt qu'en dehors de ce qui est prévu par le langage (avec toutes les vérifications), on ne peut rien faire (sinon il ne peut plus vérifier et on perd l'intérêt du langage). Par exemple, dans certains jeux, il existe des allocateurs qui permettent d'allouer de la mémoire qui sera utilisée uniquement dans la construction de la frame courante, donc on peut désallouer tout d'un seul coup à la fin de la construction (voir ici pour les explications). L'avantage, c'est que l'allocation et surtout la désallocation sont très rapides. Faire ça en Rust, je demande à voir.

Dire qu'on va faire qqch et dire qu'on l'a déjà fait, ce n'est pas pareil. J'attends de voir un jeu complet et fini avec Rust et avoir le retour d'expérience.

Dans beaucoup de jeu, la gestion de la mémoire est un composant critique qui est optimisé pour différents usages. Avec Rust, je pense qu'on n'a pas le choix, le modèle mémoire va venir se mettre en travers des développeurs à un moment donné et là, il n'y aura aucune solution.

Franchement, ça se tente en game jam ce genre d'idées. Tu mets des licornes et c'est bon, tu as le jeu de l'année.