[F] Utilisation du C++ - Page 1

Ce sujet est issu d'une discussion ayant dérivé sur deux thèmes distincts. Pour vous rendre sur le sujet d'origine, suivez ce lien.

./23730 > tout ?
c'est exactement ce qu'on s'efforce d'appliquer au taff. ptet un peu moins radical niveau C++ bashing, on se sert de quelques features utiles pour gagner du temps de dev dans ce qui n'est pas trop critique, mais dans l'approche et la mentalite, c'est tout a fait ca.
Et c'est a l'oppose de la philosophie "classique" de l'OO qu'on apprend dans les ecoles (dans toutes celles que j'ai vu en tout cas)
ya des gens qui comprennent pas qu'on utilise pas la std ou qu'on recode des trucs in-house qui ont dja des chiees d'implems ailleurs.. bah la c'est tres bien expose

(il dit rien de vraiment nouveau ou original, mais il presente les choses bien, et surtout c'est a cpp-con, face a plein de fanboys, et il se paye qd meme le luxe de basher le C++ et de sortir sa quote de fin "design patterns are for brainless programmers blabla" )

dommage que t'aie pas le temps de regarder (ca se regarde bien en background en faisant d'autres choses )

c'est tres interessant la video, et j'adore les questions a la fin ( et les commentaires sur la video )

Sinon, lie a la video:
http://realtimecollisiondetection.net/blog/?p=44
suivit de http://realtimecollisiondetection.net/blog/?p=81


Je suis d'accord avec lui et sur et surtout sur point a la con, le nom de ces trucs que je trouve plus confusant qu'autre chose. Genre il parle du "visitor pattern" je me demandais ce que ca pouvais etre, j'ai cherche dans google je suis tombe la dessus:

http://fr.wikipedia.org/wiki/Visiteur_(patron_de_conception)

La gros WTF sur ma tete o_O

Je clique sur "patron de conception" et on tombe sur http://fr.wikipedia.org/wiki/Patron_de_conception qui est donc, pour certains, la traduction de "design pattern"

Deja rien que mot a mot la traduction est foireuse... Mais on atteinds le sommet la :/

Et quand je lit ce genre de propos:

In object-oriented programming and software engineering, the visitor design pattern is a way of separating an algorithm from an object structure on which it operates. A practical result of this separation is the ability to add new operations to existing object structures without modifying those structures. It is one way to follow the open/closed principle.
In essence, the visitor allows one to add new virtual functions to a family of classes without modifying the classes themselves; instead, one creates a visitor class that implements all of the appropriate specializations of the virtual function. The visitor takes the instance reference as input, and implements the goal through double dispatch.

Soit mon cerveau explose devant ce genre de propos, soit j'ai l'impression d'etre un M. Jourdain.... (personellement je n'ai jaiams reussi a suivre plus de 5min un "discours" sur le bienfait des DP sans un ennuit formidable ou l'envie de meutre sur celui qui essaye de me persuader que c'est le bien)

Pattern ça veut dire patron en couture, juste comme ça en passant.

Ca signifie aussi motif, dessin, modele...

Je te laisse deviner quel est le sens voulu par les auteurs du truc a l'origine, mais c'est surement pas "patron"

Ah, le design pattern visitor, on me l'a conseillé une fois, j'ai regardé, je suis parti en courant j'ai quand même l'impression qu'il y a toute une partie de la POO qui me sera à jamais, par malédiction, intrinsèquement hermétique

Presque pareil pour moi :

Folco (./23738) :
j'ai quand même l'impression qu'il y a toute une partie de la POO qui me sera à jamais, par malédiction, intrinsèquement hermétique

Je dois pas avoir le cerveau câblé pour

Bon après, je prends ça pour une faiblesse de ma part : pas que tous les design patterns soient géniaux, je pense pas : ils sont juste là pour résoudre des problèmes, pas pour être propres. Mais ne pas réussir à comprendre et adopter une manière de pensée qui pourtant, est loin d'être idiote, et même plutôt puissante, c'est pas glorieux à mes yeux.

Mais as-tu pris le temps d'étudier ça en détail ? Ce n'est pas parce que tu n'as pas compris un truc en 5 minutes que tu n'es pas capable de le comprendre, peut-être simplement que ça nécessite davantage de temps

Pour ce qui est d'adopter, c'est une autre histoire. Il y a des méthodes qui conviennent mieux à certaines personnes et situations que d'autres. Heureusement, il est rare qu'il n'existe qu'une seule "bonne" façon de faire les choses.

(./23737 : dans la page de discussion de WP FR, on voit que la traduction française de ce terme est un truc inventé par eux, et comme souvent avec WP FR c'est une ânerie...)

Folco : Tu n'as pas lu alors. Il ne sont pas là pour apporter une solution a un problème. Ils sont la pour mettre des problèmes rond dans des solutions triangulaires, avec un marteau rouge.

Relis les deux pages que j'ai cite plus haut

ok (génial ton synopsis )

Ce que je retiens surtout de la vidéo c'est que le mec fait du C++ sans exceptions, sans templates, sans STL, sans héritage multiple, sans surcharge d'opérateur, sans RTTI, voire même sans classes, et quand à la fin on lui demande très justement pourquoi il fait pas plutôt du C, il ne trouve rien d'autre que "parce que le support C de MSVC est pourri"

Ceci dit, le fond de son argumentation n'est pas dénué de bon sens. En fait, il dit exactement la même chose que ce que disent les utilisateurs de langages fonctionnels depuis 50 ans : il faut raisonner en priorité sur les structures de données et appliquer des fonctions simples qui font une transformation bien précise sur ces données. C'est mieux pour tout un tas de raisons, dont celle qui l'intéresse le plus en tant que développeur de moteur de jeux : la performance.


Godzil : je te rassure, la page wikipedia sur les visiteurs est absolument incompréhensible, même pour ceux qui savent très bien ce que c'est. A mon avis, c'est simplement parce qu'il n'y a pas la moindre explication sur la raison pour laquelle ce design pattern existe en premier lieu. Et c'est souvent le cas pour les design patterns en général. On oublie souvent de dire qu'ils existent pour contourner les limitations du système de typage parfois très contraignant de certains langages tels que C++ ou Java. En ce qui concerne les visiteurs, l'objectif est d'étendre les opérations qu'on peut appliquer sur une structure de données (en gros, comment rajouter une méthode à une hiérarchie de classes), sans modifier le code existant et sans affaiblir le typage. Je passe l'explication détaillée, qui est hors-sujet dans ce topic, mais si y'en a qui veulent essayer de comprendre un peu mieux pourquoi ça existe, il faut s'intéresser à un problème plus général qui s'appelle "the expression problem".

Godzil (./23743) :
Folco : Tu n'as pas lu alors. Il ne sont pas là pour apporter une solution a un problème. Ils sont la pour mettre des problèmes rond dans des solutions triangulaires, avec un marteau rouge.

Ils pourraient se reconvertir en politiciens.

Mais surtout un marteau rouge, c'est le point clef de la phrase

Le design pattern Visitor est sympa (au sens que le code utilisateur est très compact) pour certains types de traitement des données. Par exemple, en XML, avec un parser SAX, la récupération de tous les éléments possédant un certain nom, ou un certain attribut.
En revanche, d'autres types de parsing de XML sont (très) désagréables à écrire avec un parser SAX, parce que c'est à l'utilisateur de gérer l'état du parsing selon les événements crachés par le parser SAX...

Le seul endroit ou j'ai utilise un pattern visiteur c'est pour traiter des AST apres avoir parse un source.

./23728 J'ai tout regarde, c'est excellent ;')

bien presente, fluide, la theorie et les arguments sont tres clairs.

ca rappelle evidemment toutes tes demos d'optimisation super excellentes que tu nous avais presentees petit a petit, je comprends que la video t'ai plu

(bien aime le "c'est a cause des gens comme vous que word met 30s a booter" )

Je suis plutôt d'accord avec nitro. Sa position est défendable dans son cas très précis, mais il passe 1h30 à cracher sur tout ce qui bouge en répétant toutes les 10 secondes "c'est un fait", "c'est comme ça", "c'est la réalité", tout en prenant des exemples complètement idiots pour appuyer ses arguments (entre les bouts de code "cas d'école" et son rant sur les design pattern dont 90% des développeurs se foutent probablement totalement). J'imagine qu'il me manque un gros disclaimer "ce que je dis s'applique au développement d'outils pour le jeu vidéo" qui s'appliquerait à toute la vidéo.

Bande d'égoïstes, pas un seul qui peut me traduire ça au lieu de me faire baver devant une video en chinois ??? #allez-même-tous-vous-faire-FOUTRE# !!!!!

Zeph: ca s'applique aussi au dev embarqué, au dev système,

C'est une conférence sur du C++ ^^ (enfin vu le contenu, pas sûr en fait...)

oui enfin ils digressent largement, ils ont aussi dans la meme serie une video sur l'utilisation de c++ dans les rovers martiens, et ca cause plus de pathfinding que de c++, sans que personne ne sen offusque

Zeph> t'as du louper genre les 10 premieres minutes ou il explique bien ce qu'est son cas de figure, ce sur quoi il bosse, et quelles sont ses contraintes?
et ouais ca s'applique aussi surement a l'embarque, c'est pour ca j'imagine qu'il cite un des talks d'avant qui portait sur le software de curiosity (et a priori des mars-rovers en general?), en disant que leur utilisation du C++ etait assez similaire.
D'ailleurs je l'ai pas regarde mais ce talk la doit etre assez interessant aussi
et le mec pretend pas faire un talk sur le C++ en general. Mais je trouve que bcp de ce qu'il dit s'applique effectivement a tous les domaines de code, C++ ou pas, jeux ou pas. Le fond de sa presentation, c'est pas tant sur quelles features du langage il utilise ou pas, mais sur l'etat d'esprit dans lequel ils approchent une problematique, pour apres la traduire en code.

bearbecue > intéressant, faudra que je regarde L'utilisation du C++ reste assez polémique même dans les grosses boîtes ; par exemple, il me semble que chez Google ils n'utilisent pas les exceptions dans les projets en C++.

.. et dans le JV. quasiment personne dans le domaine n'utilise les exceptions. trop merdique, trop de surcouts "caches". Sur le papier c'est joli, concretement c'est une autre histoire. (en plus c'est pas supporte par toutes les plateformes sur lesquelles bcp de devs de jeux doivent build )
et les rares que j'ai vu qui les utilisaient, c'est que sur PC. Et parcequ'ils n'ont jamais dev que sur pc, et que les PC, c'est des machines tolerantes niveau goritudes. "ca passe"...
ils ont des devs qui ont dev ailleurs que dans le JV avant, et qui ont garde leurs habitudes. Le jour ou ils doivent avoir plus de perfs et ou ils peuvent pas juste acheter un nouveau pc plus puissant (lire: ils doivent faire un portage console, et les concurrents qui savent dev correctement sur ces plateformes font des jeux qui les lattent niveau technique ), ben ils sont dans la merde, et ils apprennent a la dure ce que c'est.

nitro:Ce que je retiens surtout de la vidéo c'est que le mec fait du C++ sans exceptions, sans templates, sans STL, sans héritage multiple, sans surcharge d'opérateur, sans RTTI, voire même sans classes"

- sans exceptions: ouais clairement
- sans templates: non, pas "sans templates", mais "sans templates pour un oui ou pour un non, juste parceque t'as repere un bout de code que tu pourrais templater" Ou juste parceque tu peux. Avant d'en avoir besoin, genre branlette intellectuelle "ouais alors jvais code un scenegraph de la mort pour mon jeu, avec des templates sur le type de node, ca va etre ultra generique, ca va etre trop classe !". Ultra generique peut etre, peu de lignes de code peut etre, dur a comprendre, a debugger, et code genere ignoble, surement.
Lorsqu'elles sont mal utilisees, ca peut etre a la fois moins lisible, moins performant, et moins maintenable. et des fois meme quand elles sont bien utilisees, sans parler des temps de compil. Au taff qd on faisait le portage PS3, on a divise l'overhead de notre lib dans la taille memoire du binaire final PAR DEUX juste en de-templatisant certains trucs et en le pensant un peu mieux. Tant que t'as pas ete concretement confronte a ce genre de pbl, et que tu a pas pu juste en avoir rien a battre, c'est assez difficile de realiser.
- sans STL: ouais, tout template, cf au dessus, ultra lourd, over-engineered, pas utile POUR SES BESOINS, et peut facilement etre battu niveau perf aussi. Si tu veux torcher une appli ou un proto rapidement, evidemment c'est super pratique et je trouverais ca tres con que quelqu'un recode sa propre classe d'array sans une tres bonne raison. Perso je m'en sers pour des tests ou des trucs rapides/protos. Certainement pas pour notre vrai soft.
- sans heritage multiple: ouais je connais quelques autres boites qui font ca. Nous on s'en sert un peu, mais plus des masses. au final ya pas tant de cas que ca ou c'est vraiment justifie. Niveau clarte, qualite de code final, et maintenabilite/facilite de refactoring, c'est pas tip top. J'ai pas encore vu de cas concret ou c'etait vraiment necessaire et ou ca pouvait pas etre re-ecrit en heritage simple.
- sans RTTI: la RTTI builtin du C++ doit gerer toute une chiee de cas differents. le pire etant sans doute le dynamic_cast avec des heritages multiples virtuels. Par consequent, en plus de generer plein de trucs dont t'as rien a branler, t'as des dyn-casts ultra lents. La encore, dans notre cas au taff, les quelques rares cas ou on a besoin de RTTI, on contourne avec des trucs tout simples, absolument pas lourds, specifiques aux besoins qu'on a, et qui sont bien plus legers et rapides que la solution ultra-generique de la RTTI builtin.
- sans classes: non, il n'a clairement pas dit ca juste sans classes pensees de facon abstraite et code-centric

pis ouais la conf est sur le C++, mais c'est pas hors sujet, il parle de leurs developpements en C++. jsais pas ca vous interesse pas en tant qu'users du C++ (ou que spectateurs potentiels d'une conference sur le C++), de savoir comment d'autres gens (brillants, probablement plus que nous tous ici), utilisent le C++, et pourquoi ils utilisent ou n'utilisent pas certaines parties?

(entre les bouts de code "cas d'école" et son rant sur les design pattern dont 90% des développeurs se foutent probablement totalement)

mais justement, meme du code ultra simple comme ca est candidat a ce qu'il dit, c'est encore pire dans des pas cas d'ecole bcp plus complexes.
Certains se vexent quand on leur demande en entretien d'embauche de recoder un strlen. Bah c'est un peu pareil je trouve. Ce qu'il montre est certes tres simple, mais extremement pertinent.
Il aurait pu montrer un cas concret plus complexe qui aurait perdu tout le monde et qui aurait bouffe les 3/4 de son temps de parole, mais ca aurait ete un peu useless non?
(et en plus, il a montre un cas concret, avec la classe Node d'ogre)

La classe "Node" c'est son seul exemple pertinent je trouve oui. Je ne connais pas le reste du code mais ça a effectivement l'air d'être un truc over-générique qui a un cout avant même de commencer à résoudre un problème, admettons. Mais les autres exemples, genre "regardez, un if sur une condition constante à l'intérieur d'une boucle c'est pas efficace", c'est ça que j'appelle un cas d'école et j'imagine que les gens qui écoutent sa présentation n'ont pas appris grand chose en voyant ça.

Mais ce qui me dérange je pense que ça n'est pas tellement le message en lui-même : ils font des choix sur leur utilisation du C++, ce sont d'ailleurs des choix qui sont assez courants chez tous les gens qui ont des besoins de perf (et ça ne se limite pas au JV et à l'embarqué), ça OK. C'est vraiment sa façon de présenter qui m'agace, c'est con mais j'aurais probablement plus adhéré si ça avait été présenté par quelqu'un d'un peu plus humble et qui n'aurait pas répété 20 fois chaque argument, surtout quand c'est sujet à débat.

bearbecue (./24) :
pis ouais la conf est sur le C++, mais c'est pas hors sujet, il parle de leurs developpements en C++. jsais pas ca vous interesse pas en tant qu'users du C++ (ou que spectateurs potentiels d'une conference sur le C++), de savoir comment d'autres gens (brillants, probablement plus que nous tous ici), utilisent le C++, et pourquoi ils utilisent ou n'utilisent pas certaines parties?

Bien sûr que c'est toujours intéressant d'avoir un tel retour d'expérience
Je trouve juste amusant que son message se résume en gros à "ne faites pas de C++". D'ailleurs il dit lui-même que si l'industrie du jeu vidéo n'était pas aussi centrée sur le C++, il ferait du C99. Et je suis parfaitement d'accord avec ça hein

-

Personnellement, je n'ai pas été convaincu et pourtant je préfère largement le C au C++ .
J'ai trouvé pas mal de ces exemples foireux et mal choisis.

Cette page ( http://blog.nuclex-games.com/tutorials/cxx/game-state-management/ ) explique comment implémenter des game states en C++, façon "les autres méthodes sont à chier, la mienne est la seule bonne".
J'ai téléchargé le programme d'exemple, dont le but est principalement d'implémenter cette classe. But de la classe : appeler les fonctions Start/Pause/Resume/Stop des différents game states, stackables, modaux ou non. Et bien il faut au moins 10 classes, 20 fichiers et 3 espaces de nom au type, je sais pas combien de milliers de lignes pour implémenter ça, alors qu'à la base on parle d'une table de saut de 4 éléments et de troiss flags qui se battent en duel. Il faudrait pas 100 lignes pour implémenter ça en asm...
Quand je vois ça, je me dis qu'en effet, certains s'amusent à créer de la surcouche pour le seul plaisir d'atteindre une forme de perfection intellectuelle (ce que je comprends très bien), mais quand même légèrement déconnectée de la machine, fabriquant ainsi un outil bien trop complexe pour des choses aussi simples.

RTTI et exceptions, c'est en effet une mauvaise chose pour l'efficacité.
Pour le reste, vu le résumé de ./24, je pense qu'il se bat surtout contre l'abus de certaines features, qui ont toutes leur utilité si elles sont bien utilisées. J'ai récemment mis des templates dans la base de code du boulot à des fins de factorisation de code, c'est quand même mieux que copier-coller-modifier (et faire évoluer indépendamment).