rewind a écrit 3416 commentaires

on est justement dans deux cas où je trouve qu'il y a énormément de place perdue en haut de la fenêtre. Que ce soit sur celle intitulée "Test" ou sur la calculatrice, il n'y a quasiment aucune information pour une occupation vraiment importante.

En fait, on a fusionné deux barres avec beaucoup d'informations en une seule, en perdant beaucoup d'informations, mais finalement, cette barre est aussi imposante que les deux anciennes réunies, sans les informations… Moi, les designers de GNOME, je les brûlerais de suite en place publique :P

Il y a une news en attente qui était en tribune de rédaction ces jours derniers, je trouve ça un peu limite de faire cette annonce en concurrence, surtout vu la qualité de l'annonce…

Après, on peut lutter contre ça ou au contraire jouer avec. Finalement, c'est aussi ça le libre, ça peut permettre de revoir le game design. Certes, ce n'est plus le même jeu après, mais au moins, des gens y jouent.

Il est probable que d'ici une dizaine d'années, les latences réseaux ne seront plus un problème pour le jeu vidéo. Mais en 2014, si on souhaite avoir un jeu accessible par Mme Michu, ou son gosse, on ne peut pas l'oublier.

Évidemment que tout le monde, à l'heure actuelle, n'a pas une super latence qui permet de jouer à tout et n'importe quoi. Mais après, si on se met à vendre qqch, il faut raisonner en terme de marché. Est-ce que mon marché, c'est l'ensemble des gens connectés à Internet ? Non, c'est ceux qui ont une bonne latence, ça représente déjà pas mal de monde et ça ne va faire que grossir.

Surtout si on veut faire du libre et qu'on est une petite structure, on ne va pas viser un gros marché, ce n'est pas cohérent. Ma stratégie, ça serait plutôt de faire simple et clair, et comme c'est libre, si qqn veut proposer des améliorations pour réduire la latence, il est le bienvenu.

Il faut simplement une procédure pour exclure les gens qui ne comprennent pas que tricher, c'est s'enlever le plaisir du jeu.

Le problème vient du fait que si tu commences à faire payer tes joueurs, tu vas aussi exclure des gens qui paient. Et rien ne dit que ça va faire venir des non-tricheurs qui paieront. Je connais au moins un jeu qui souffrent de ce problème : plein de moyen de tricher, aucune volonté apparente des équipes de dev de changer ça, des grandes déclarations mais finalement, on laisse les tricheurs en place parce qu'ils paient bien (sauf s'ils trichent pour ça aussi, mais ça, ça sera corrigé vite).

Dans un jeu vidéo, une telle resynchronisation nuit souvent à l'immersion (syndrome du joueur téléporter à cause d'un pic de latence), et on laisse donc au client une certaine marche de manoeuvre, le serveur acceptera, jusqu'à une certaine mesure, la position d'un client même si elle est différente de celle qu'il a lui même calculé.

Tu vois, tu pointes toi-même le problème de conception qui facilite la triche. Donc, tu valides quelque part ce que je dis. Après, la solution, elle va venir d'une part de la rapidité des réseaux (qui font qu'on aura moins de latence) et de l'architecture (logicielle) des serveurs qui sauront exploiter les les multi-processeurs ou tout autre technique qui permet de traiter les données plus rapidement. Sans doute aussi par un changement des règles dans les cas critiques (moins de joueurs par carte, etc).

Tu tiens vraiment à ce que tes commentaires descendent encore plus vite dans les négatifs ?

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.