Salut tout le monde,

J'aimerais avoir votre avis sur les pointeurs. Dans le développement d'un jeu vidéo, vous utilisez des raw pointer ou des smart pointer ? et pourquoi ?

Personnellement, j'ai toujours utilisés des raw pointer par pur habitude et parce que ça me permet de gérer la mémoire comme je veux.
J'ai tendance à me dire que dans les jeux vidéo, il vaut mieux gérer la mémoire manuellement pour avoir les meilleures performances possible (par exemple, en se servant de temps de chargement pour nettoyer la mémoire).
Cependant, je viens d'acheter un livre en c++ (Procedural Content Generation for c++ Game Development) où ils n'utilisent que des smart pointer. Je suis certains que les auteurs du livre sont bien plus calé en c++ que moi mais bon, ca me turlupine quand même cette histoire.

J'attend vos avis, je me réjoui de voir les résultats et de pouvoir peser le pour et le contre.

La mémoire tu la gère aussi comme tu veux avec les smarts pointer, c'est toujours toi qui décide, c'est juste plus simple et ça permet d'éviter quelques fuites de mémoires provoquées par des oublis.

Utilise les smart pointers. Par habitude, j'utilise les raw pointers mais c'est une mauvaise habitude. Dans le domaine des jeux vidéo, ils utilisent des garbage collector en C++ pour ne pas avoir de fuite de mémoire c'est dire...

On peut faire des fuites de mémoire avec des smart pointer au passage. Si tu veux vraiment gérer la mémoire, tu dois te faire un custom allocator de mémoire qui gère toute et les gens qui utilisent ta allocator font une simple demande qui retourne un pointer (raw ou pas). L'allocator se chargera de gérer la mémoire ou de t'avetir en cas de fuite de mémoire.

Exemple d'utilisation :

Int* ptrInt = Allocatior::new<int>();

Quelque chose de ce genre là. Au passage tu peux surcharger l'opérateur new...

Je ne suis pas (encore) pro, mais d'apres les infos que j'ai pu glaner, voila ce qui ce dégage :

• Si tu débutes : utilise des smart pointer.
• Si tu as un peu d'XP et tu ne cherche pas la perf a tout prix : Smart Pointer.
• Si tu as de l'XP et tu cherche la perf : Smart Pointer avec une autre lib que la STL.

• Si tu es un pro et que tu travail a très bas niveau (exemple sur console) et sur un projet contenant des millions de ligne de code : n'utilise pas la STL, écrit ta propre lib avec des customs allocator. (cad : la manière dont tu vas gérer la mémoire.)

Donc si tu était dans le dernier cas, techniquement tu ne serais pas ici a poser la question, donc utilise les smart pointer, mais essaie de les manipuler de tels sorte que tu puisses gérer leur cycle de vie.

Ah j'oubliais parfois quant tu utilises des lib C, t'es un peu obliger d'utiliser les raw pointers car les API de la SDL ou OpenGL te renvoie des raw pointers.

Mais dans ton code il est préférable d'utiliser les smart pointer car les compilateur récent optimise au maximum ton et le fait de passer en Raw Pointers casse cette optimisation.

A moins d’être sûr a 200% de ce que tu fais, vaux mieux utiliser dans un premier temps les smart pointers.

On peut faire des fuites de mémoire avec des smart pointer au passage.

J'ai dis que ça évitait les fuites de mémoire provoqué par des oublis, si t'as une fuite de mémoire avec un smart pointer c'est pas dû à un oublie mais à une mauvaise utilisation.

Si tu as de l'XP et tu cherche la perf : Smart Pointer avec une autre lib que la STL.

Les smart pointer de la STL ne sont pas bien optimisés ?

La STL a été conçu pour une utilisation standard (pas pour le JV), je ne sais pas si les Smart Pointer sont suffisamment optimiser par rapport a une autre lib, en tout cas il y a la EASTL. d'Electronic Arts qui augmente les perfs jusqu’à 20%.

(Bon après ça doit surtout jouer sur une refonte des conteneurs plus que des pointeurs)

J'ai quand même l'impression que coder son propre "allocator" est préférable dans le jeu vidéo.
Je vais peut être dire une conneries, mais j'imagine qu'on pourrait centraliser tous les pointeurs dans une classe qui gérerait leur cycle de vie et faire un "clean" quand j'ai besoin de delete tous les pointeur inutiles. Ça me permettrait de contrôler quand je fais mes delete (pendant des chargement ou dans les menus par exemple).

Par contre, l'EASTL à l'air vraiment bien. Quelqu'un l'a déjà utilisé et peut donner un feedback ?

Tu viens de décrire ce que fait un smart pointer, sauf que c'est pas une class mais un Template.

Le truc avec les pointer raw ou smart c'est qu'il ne faut pas les créer et les détruire pendant les phases de jeu, mais pendant les chargement de niveau.

Je dois pas comprendre les smart pointers alors.
Je croyais que c'était juste des pointeur qui gérais eux même leur cycle de vie. En gros, pas besoin de les delete, ils le font automatiquement.
Je ne savais pas qu'on avait le contrôle sur le cycle de vie.

Le 16 juin 2016 à 11:29:35 Dam979 a écrit :
Par contre, l'EASTL à l'air vraiment bien. Quelqu'un l'a déjà utilisé et peut donner un feedback ?

Je l'avais recuperé. Ca compile nickel. Par contre je n'ai pas trop pratiqué.

Mais je comfirme, dans le jeu vidéo on n'utilise jamais la STL. Aucun optim en interne. Toutes les boites ou j'ai bossé, l'équivalent avait été recodé. Dans Unreal aussi, il y a des conteneurs refait par Epic.

Oui on peux le voir ainsi également, du coup tu fais de la programmation haut niveau sans te soucier de la gestion de mémoire, c'est comme programmer en Java ou C# dans ce cas.

Mais en utilisant certaine règles ont peux gérer leurs destructions.

Tu peux garder l'implémentation de std::sort par contre. Pour 10 000 éléments, on tourne autour de 600-800ns ce qui est excellent (meilleur que celui de Unreal au passage...).

"ns" c'est l'acronyme de quoi ?

Nano secondes, une unité de temps.

Je pense pas que ce soit ça, j'vois pas pourquoi on utiliserait une unité de temps pour calculer la vitesse d'un algorithme, ça a pas de sens.

Avoir un bon algo c'est bien mais ça ne fait pas tout, il faut qu'il respecte l'architecture et qu'il correspond au mieux au données qu'il vas traiter.

Un bon algo avec une mauvaise implémentation peux généré des miss cache au niveaux des traitements et là seul le temps peux déterminer si ton algo est assez rapide par rapport à d'autres algo.

Je vois pas vraiment en quoi une valeur comme "600 nanoseconde" balancé comme ça sans rien de plus peut aider quiconque à juger de l'optimisation d'un algorithme en fait.

Le 17 juin 2016 à 13:54:10 lokilok a écrit :
Je vois pas vraiment en quoi une valeur comme "600 nanoseconde" balancé comme ça sans rien de plus peut aider quiconque à juger de l'optimisation d'un algorithme en fait.

En faite, mon poste est là non par pour dire "Oui c'est 600ns"... Il est là pour t'informer a faire un comparatif par rapport à d'autre algorithme similaire pour que tu puisses faire une comparaison.

Tu prends plusieurs algorithme de trie, toujours sur le même array (10 000 habituellement, des fois plus) et tu recommence le même algorithme une dizaine de fois pour avoir une moyenne.

Par exemple le sort de Unreal est de 1000-1200ns, celui de la STL 600-800ns sur le même array. Après tout dépend des données aussi et du contexte mais la moyenne donne ca.