rewind a écrit 3434 commentaires

Mais en même temps, je pense que ça doit être une misère pour qui s'occupe de la triche en ligne d'avoir aussi facilement accès à tous les paramètres…

Pas vraiment. Pour tous les jeux où les paramètres sont importants, même quand ils sont propriétaires, les formules sont retrouvées en deux temps trois mouvements. Les avoir directement ne changera rien. Après, pour le reste de la triche, c'est plus la manière de coder et de concevoir qui va permettre d'éviter la triche ou pas.

Ce que tu pointes est juste mais je pense que tu ne vas pas assez loin dans la réflexion. Le libre fonctionne parce qu'il est gratuit, mais aussi parce qu'on peut avoir la main sur le code et pour tout l'écosystème autour (je fais vite). Actuellement, les jeux libres ne se différencient pas de leurs homologues propriétaires, ils sont juste libres (et gratuits pour l'immense majorité).

De la même manière que les jeux FaceBook ne sont pas les mêmes que les jeux traditionnels sur PC, qui ne sont pas les mêmes que les jeux console, je crois qu'il faut trouver ce que peut apporter comme plus un jeu libre. Je n'ai pas de réponse pour l'instant, mais à un moment, il va falloir se poser la question : qu'est-ce qu'on pourrait faire avec un jeu libre qu'on ne pourrait pas faire avec un jeu propriétaire ? Libre et gratuit ne suffiront pas, c'est clair.

Je pense surtout qu'il faut du temps avant de trouver un modèle économique adapté aux jeux libres. Déjà pour le libre, il a fallu bien 10-15 ans avant qu'une boîte arrive à survivre en faisant du libre. Avec les jeux libres, on n'est qu'aux balbutiements, ça commence à monter en puissance, on peut avoir quelques toute petites boîtes qui arrivent à survivre, mais pas encore des moyennes entreprises. Ça viendra, mais il faut laisser du temps.

Pour moi, tous les indicateurs passent au vert ces derniers temps. On a des pilotes (libres) qui commencent à ressembler à quelque chose et qui progressent vite. On a une infrastructure graphique qui prend de la maturité (et Wayland en est la meilleure preuve). On a des bibliothèques et des frameworks éprouvés qui permettent de faire de bons jeux dans quasiment tous les genres. On a des entreprises qui investissent dans tout ça, même si elles continuent à faire du propriétaire geôlier. Si on compare avec 5 ou 10 ans en arrière, on a sacrément évolué dans le bon sens. Attendons et ça arrivera.

Généralement, la «forme normale de Coplien» (première fois que j'entends ce terme) est utilisé dans le cadre de ce qu'on appelle le Rule of Three : si on implémente un des trois suivants, on implémente les deux autres : constructeur par copie, affectation, destructeur. Et depuis C++11, on a presque le Rule of Five avec le constructeur par déplacement et l'affectation par déplacement. Mais en fait, vu qu'on a maintenant des classes qui gèrent ce genre de cas très bien (shared_ptr, unique_ptr), on a un Rule of Zero (parce que les méthodes par défaut feront exactement ce qu'il faut).

Du coup, je pense que le livre s'est arrêté avant C++11.

Ce n'est pas la question. reno fait semblant que C++ est un langage récent mais se traîne des headers. C'est complètement à côté de la plaque de comparer C++ avec des langages conçus récemment. On peut affirmer qu'on aimerait bien une notion de module, sans oublier que les headers de C++, ça ne date pas d'hier non plus.

C'est marrant, un coup il faut regarder que les nouveautés et s'appliquer à oublier tout le reste, un coup il faut bien garder en tête qu'il est super vieux.

C'est pourtant pas difficile : C++ est un langage qui évolue mais qui garde une compatibilité avec les version antérieures et avec le C. Il n'y a aucune contradiction à vouloir utiliser les trucs nouveaux quand ils sont là et à utiliser les trucs plus anciens quand ils n'ont pas (encore) de remplaçants. Si vous voulez vous amusez à pointer tous ces vieux trucs inutiles voire parfois encombrants de C++, vous n'avez pas fini, mais ça n'apportera pas grand chose au débat.

Non mais faudrait arrêter de faire croire que C++ date d'hier hein. C++ a une compatibilité très large avec le C, lui-même ayant été créé dans les années 70 ! Oui, on a toujours des headers en C++, et alors ? Ça empêche le monde de tourner ? Non, ça marche très bien. Oui, ça viole le DRY et alors ? Ça permet aussi d'avoir une documentation des fonctions sans se traîner le corps de la fonction. Ce n'est pas un drame.

Et c'est devenu quoi cette affaire avec le féminisme (dont on peut retrouver quelques traces ici ou là) ?

En France, c'est l'État qui collecte l'impôt et les taxes. Enfin, depuis qu'on a supprimé les fermiers généraux. EcoMouv, c'est un retour en arrière de plus de 2 siècles, en plus de nous coûter horriblement cher.

Pourquoi ce serait «facile» d'avoir comme règle de codage «pas de unsafe a moins qu'il y ait une justification» et que ce serait difficile d'avoir le même genre de règle pour C++ ? La règle est juste un poil plus longue mais pas tant que ça (pas d'exceptions, de RTTI, d'héritage multiple ; et pour C++14, pas de new/delete). Si tu es obligé de mettre une règle pour Rust, c'est qu'il n'est pas si sûr que ça. Et dans ces cas là, C++ est tout aussi sûr. Parce que mettre des règles, ce n'est pas pour les compilateurs, c'est pour les humains.

Ce que je te dis, c'est que, certes, Rust apporte quelques sécurités mais ne t'empêche nullement de faire de la merde parce que tu peux passer par unsafe. Et le fait que ce soit marqué unsafe, ça ne va pas gêner ceux qui font de la merde. Le problème, il n'est pas technique, il est humain. Et C++, là dedans, il permet lui aussi d'avoir quelques sécurité (pas les mêmes que celles de Rust) mais il permet aussi de faire de la merde (sans préfixe unsafe). Comme le problème est humain, l'un n'est pas mieux que l'autre.

Oui, comme en Rust. Et tout le monde s'en fout la manière dont c'est implémenté, l'important c'est que ça marche comme c'est spécifié. Le fait que ce soit dans la bibliothèque standard ou dans le langage lui-même ne change pas grand chose à l'affaire.

Non certains langage accepte par défaut que tu fasse de la merde et d'autres te permettent de faire de la merde si tu lui dis « ok je sais que je suis entrain de faire de la merde ». Bien sûr la limite entre les 2 est floue, mais le C++ est clairement plus dans la première partie que dans la seconde.

Donc, tu es en train de dire que mettre un préfixe «unsafe» devant tous les trucs gorets, ça change absolument tout ? S'il y a un «unsafe», c'est bien que ça doit servir à un moment, non, sinon ça ne serait pas là ? Et bien moi, je préfère qu'on ne mette pas un «unsafe» et qu'on apprenne à l'utilisateur ce qu'il ne faut pas faire et pourquoi, plutôt que d'avoir un préfixe «unsafe» inutile parce que du coup, on se demande bien ce que ça peut faire là. Et puis si les gars qui codent l'utilisent, c'est qu'on doit pouvoir l'utiliser, donc c'est pas si unsafe. Donc de toute façon, dans tous les cas, tu trouveras toujours un couillon qui utilisera mal le langage (préfixe «unsafe» ou pas) et qui fera de la merde.

Oui mais pourquoi le reprocher au PP, plus qu'aux autres.

Parce que le PP prétend faire de la politique autrement ?

On utilisera std::make_shared (déjà dispo en C++11) et std::make_unique (en C++14)

Tu va peut être être surpris mais le C++ n'a pas 3 ans, donc il faut supporter le code plus ancien.

Oui, et ce code plus ancien, a priori, il doit bien marcher et ne pas faire trop de connerie, sinon ça serait corrigé.

Tu as quoi pour vérifier que tu ne fais pas des usages dommageables ? Tu peut utiliser le dernier icc, g++, clang++ en appliquant la dernière version de la norme, tu pourra toujours faire un brk(2) des familles. Un langage sûr c'est un langage qui te l'interdit.

brk(2) est un appel POSIX, il n'est pas dans la norme C++.

Ceux qui ne savent pas ce qu'est le polymorphisme ? ;-)

Ceux qui utilisent GNU Bison…

C++ est très "unsafe" (pointeurs nuls, gestion manuelle de la mémoire

Dire que la gestion manuelle de la mémoire est «unsafe», c'est vraiment un truc à la mode ces dernières années. Surtout qu'avec C++11, on n'a quasiment plus aucun besoin de gérer la mémoire. En C++14, on n'aura même plus besoin de faire des new et delete, ils seront masqués complètement. Qu'est-ce qu'on reproche encore à C++ à ce niveau ? Des fantasmes sans doute. Le C++ n'est pas du C !

Qu'est-ce qui le différenciera de Rust ? Plus grand chose à mon sens. Ceux qui font de la merde avec la gestion mémoire, ils le savent en C++, il n'ont pas besoin de mettre un préfixe unsafe.

sémantique compliquée, unions, mutabilité par défaut) même si pas autant que C,

La sémantique de C++ n'est pas plus compliquée que celle de Rust. Juste différente. Question de goût.

Les unions… Hormis dans des cas extrêmes et bien identifiés, qui utilisent des unions ?

écrire un programme concurrent correct en C++ est très difficile.

Faux ! Ce qu'il manque à C++, c'est un modèle de programmation dans la bibliothèque standard. C++ laisse l'utilisateur le définir. En Rust, comme en Go d'ailleurs, le modèle de programmation est imposé. Maintenant, en C++, tu peux très bien trouver des bibliothèques comme TBB qui permettent d'avoir de la concurrence très facilement.

Avec ta définition, un vieux langage ne pourra jamais être un bon langage. Parce qu'un vieux langage se traînent nécessairement une dette technique dont il est parfois difficile de se débarrasser, surtout quand le langage en question est une norme ISO et est aussi répandu que C++.

Moi, je trouve que C++ est un bon langage.

J'avoue que si on me demandait par quoi j'aimerais que le c++ soit remplacé

Pourquoi vouloir remplacer C++ ? Depuis C++11, honnêtement, c'est devenu un vrai plaisir d'écrire du C++ et ça va être encore mieux avec C++14 et C++17.

Et le patch est là

Ha oui, mea culpa, je n'avais pas vu la NdM. Ça ne change pas grand chose au fait que ce lien devrait disparaître, à mon avis.

J'ai lu aussi le contenu initial. Mais je ne comprends pas cette demi-mesure : on enlève le texte (ce qui arrive quand même (heureusement) assez rarement ici), mais on laisse un lien vers un site raciste. Les autres liens sont suffisants pour comprendre, pas la peine de garder celui-ci. Et si on pouvait directement supprimer tout le journal, ça ne serait pas un mal. Il est tout à fait possible d'avoir un débat sur ce sujet dans un nouveau journal qui présente les faits de manière plus «neutre» (et la barre n'est pas très haute quand je dis ça).

Parce que bon, à ce jeu là, on va trouver des gens qui n'aiment pas les autres sites non plus.

La question n'est pas d'aimer ou pas les sites.

Le but ici c'est pas de définir une ligne éditoriale politique, mais s'assurer que l'expression des idées est faite dans le respect de chacun (et donc sans propos injurieux, par exemple).

LinuxFR est sous juridiction française. Et en France, on n'est pas aux États-Unis, la liberté d'expression a des limites. En particulier, le racisme et l'homophobie ne sont pas des opinions mais des délits, punis par la loi. Après, tu peux trouver ça con, mais c'est comme ça actuellement. Donc faire un lien vers un site qui pratique ouvertement le racisme, l'homophobie et d'autres trucs interdits également par la loi (genre le négationnisme) ne me paraît pas être la meilleure des idées.

Est-ce qu'un modérateur pourrait enlever le lien vers fdesouche ? Parce que bon, voilà quoi.

On peut prendre le problème différemment : est-ce que tu joues en guilde avec des gens que tu connais déjà ou est-ce que tu rencontres des gens dans le jeu et tu décides de créer une guilde ? Le cas 1 me semble plus courant que le cas 2.

La plupart des MMORPG sont de qualité moyenne à mauvaise. C'est à la mode, donc il y en a beaucoup. Mais ce qu'on pouvait accepter d'un MMORPG il y a quelques années (et que tu décris), on l'accepte moins maintenant, et il existe aussi des MMORPG de bonne qualité.