Ce n'est pas une question de performance : la SFML est optimisée, c'est à dire offre son plein potentiel, pour le C++ je dirais.

Je n'ai jamais utilisé le binding C de la SFML, cependant j'imagine qu'il est tout aussi rapide, mais moins adapté.

Je n'ai pas dit grand chose sur la difference pointeurs/reference parce qu'il n'y a pas grand chose a en dire.

La difference principale est qu'une reference n'est pas reassignable alors qu'un pointeur l'est. Lorsque l'on passe une refernce en parametre, apres compilation, l'assembleur est le meme que si on utilisait un pointeur.

La difference principale est au sein de la meme fonction. Une reference EST l'objet reference, pas un pointeur vers lui. Comme les references ne sont pas reassignable, le compilateur a la vie simplifie en ce qui concerne les problemes d'aliasing. En pratique, je n'ai jamais vu de difference de performance.

La difference est principalement au niveau de la syntaxe, les references sont communement utilise pour etre syntaxiquement equivalente a l'objet en lui meme

Du coup tu ecris une fonction void foo (const bar& b); et tu utilise b comme si il etait passe par copie. Mais comme c'est une reference, il n'y a pas de deep copie de l'objet. comme l'objet est constant, il n'y a pas de risque de le modifier.

On utilise les references aussi comme retour d'appel de fonction pour retourner un objet qu'on ne veut pas copier mais pour lequel on veut un access "directe" syntaxiquement. Par exemple lors d'une surcharge d'un operateur[].

J'ai toujours trouve que l'utilisation des references vient principalement pour avoir une compilation "unique" et faire marcher les templates et les abstractions de code sans avoir a ecrire une version pour les type primitif et une version pour les types complexe.

Au niveua des pointeurs, le programmeur C++ l'utilise principalement dans les couches de bas niveau du programme: interface hardware ou avec un autre langage, allocation memoire, ou j'ai besoin de vitesse donc il me faut un vrai pointeur. Dans tous les autres cas, les pointeurs sont typiquement abstrait dans un iterateur ou une classe de plus haut niveau quelconque pour ne pas avoir a se faire chier a les trimbaler sans se les faire peter dnas les doigts.

PS: comme d'habitude, il y a autant de facon d'ecrire du C++ que de programmeur C++. donc, YMMV.

Oui donc références ou pointeurs, c'est du pareil au même dans la plupart des cas.

La seule fois où j'ai du vraiment utiliser un pointeurs, c'est quand j'ai du renvoyer un tableau à deux dimension :
return **monTab;

Ensuite pour les scripts dans les jeux 3D je pense qu'il y a autant de façons que de programmeurs.
On peut autant passer par des calculs de positions, que par des objets invisible comme l'a dit LEMOKH.

Merci pour les réponses !

C'est un peu plus safe d'utiliser les reference dans du code haut niveau, pour être sur des types que tu passes (on peut utiliser des void* mais pas des void reference), parce qu'elles sont pas réassignables et compagnie. Mais tu seras obligé d'utiliser les pointeurs dans ton code à certains endroits.

Oui, je m'en doute !

Je voulais juste savoir si utiliser l'un ou l'autre influer beaucoup sur les perfs / code, mais à première vu c'est celui que l'on préfère !

"Oui donc références ou pointeurs, c'est du pareil au même dans la plupart des cas. "

Ouais mais non quand meme. L'utilite des pointeurs est aussi essentielle des que l'on manipule des classes abstraites pour simuler des Interface en Java par exemple. Les differences under the hood sont un peu pointues a expliquer sur un forum si tant est que cela soit essentiel de repeter ce que Google sait deja... donc je te conseille d'aller jeter un coup d'oeil aux entrees "What's the difference between pointers and references in C++".
Ou des que l'on veut avoir des structures de donnees un peu plus exotiques (ou pas).

Le bon conseil dans tous les cas pour les neophytes c'est : utilise les references et evite au possible les pointeurs (au possible voulant dire : si le compilateur ne rale pas).

La phrase des "interface en Java" est trompeuse. Je voulais dire des interfaces en POO.

Par ailleurs, commentaire qui n'engage que moi, l'absence de ce concept essentiel de la POO de maniere simple et elegante en C++ m'a toujours fait conseiller de ne jamais o grand jamais apprendre la POO sur le calque partiel et parfois opaque du langage C++ mais sur des langages comme Java ou C# (avec une preference pour C# pour sa documentation et son architecture un peu plus unifiee que Java peut-etre).

D'accord, je vais aller voir ça ce soir !

Et oui, j'utilise au possible les références, et dès que il me cries dessus je passe en mode pointeurs
Merci de ta réponse !

Je reprends sur un point de détail, pour tenter de comprendre.
Je ne connais pas la doc de C#, mais pourtant, l'un des principaux points forts de Java est sa doc (JavaDoc), que plusieurs langages ont ensuite repris le principe.
Que reproches-tu à la JavaDoc (c'est ma curiosité qui pose la question ) ?

Que la premiere documentation c'est le code lui-meme. Avoir des noms de classes assez souvent tres compliques, alambiques, pas toujours self-explanatory au profit d'un design pattern archi OOP ouvertement vaseux c'est jamais tres simple pour le neophyte de s'y retrouver (et ennuyeux pour le confirme).
La javadoc j'ai connu plus sexy, enfin de ce que je me rappelle, la doc msdn est tres simple.

N'allez pas voir la s'il vous plait une critique du langage Java en lui-meme s'il vous plait. D'une je ne critique que les API qui vont avec, de deux je ne critique que l'aspect pedagogique pas forcement evident compare aux API de Microsoft qui sont plus simples a comprendre et donc a manipuler.

Marrant, depuis que je code en Java, je n'ai jamais eu de souci de nommage (avec l'API principal). Les noms étaient soit ceux que je pensais, soit proche de ceux-ci.

Pour la doc MSDN, j'y ai été quelque fois, et je m'y paume toujours facilement. Peut-être parce que je n'en ai pas vraiment besoin (donc pas besoin de comprendre comment elle fonctionne).

Merci d'avoir répondu

Avec le temps on s'habitue aussi a la logique de l'OOP, pour les neophytes je trouve ca un peu plus confu. Tout cela reste bien evidemment assez subjectif et sans grande argumentation de ma part derriere. Les deux sont des langages et des API de base totalement abordables (comme a peu pres tous les langages du monde de toute facon....).

Personnellement, je trouve la POO bien plus logique que le séquentielle.

Il m'arrive souvent de faire des dessins sur paint pour voir ce qui se passe et ce que je dois faire, chose qu'avec le séquentielle c'est plus chiant.

Puis on peux facilement se représenter les objets dans nos têtes.

J'ai un objet Ennemie. Cette Ennemie peux :
-Marcher
-Attaquer
J'ai un objet Entité qui fais ces actions, je peux donc dire que Ennemie est une Entitée, il y a donc héritage.

Je trouve ça assez facile, bien qu'à mes débuts, je transformais tout et n'importe quoi en objet !

"La seule fois où j'ai du vraiment utiliser un pointeurs, c'est quand j'ai du renvoyer un tableau à deux dimension."

Selon les cas, c'est inteligent ou ca ne l'est pas. Si le tableau "appartient" a la class qui le retourne alors tu es tranquile. Parcontre, si le tableau est alloue et t'es retourne, alors la question de qui desalloue et comment apparait. Pour resoudre la question, on aime bien les approche a base de refcounting comme auto_ptr.

Le tableau était dans ma class map, et je devais l'envoyer dans ma class entity, je voyais pas d'autre moyen !

Du coup j'avais un pointeur qui récupérait le tableau, que je supprimait.
Delete **map;
map = 0;

Après : "Pour resoudre la question, on aime bien les approche a base de refcounting comme auto_ptr."
Je ne vois de quoi tu parles, je vais aller voir ça !

Je viens de voir :

Au lieu d'avoir :
int* truc;
truc = new int(50)

delete truc;
truc = 0;

on aurait juste :
auto_ptr<int> truc;
truc = new int(50);

Donc pour récupérer mon tableau, j'aurais du faire :
auto_ptr<World> world;
world = new World()->getMap("level1.txt");

Concernant les librairies graphiques j'ai testé allegro et je peux te dire que cette librairie est très bien et performante.
Par contre, elle a un défaut: pas de code internet (tcp/ip).
Donc si tu veux faire un jeu multi online il faudra passer par une librairie supplémentaire dédiée uniquement à ça!

Ensuite, j'ai jeté un coup d’œil à SFML et je trouve le code extrêmement simple et très bien intégré en plus au C++. De plus cette librairie gère également le tcp/ip.

A toi de voir ensuite mais personnellement mis à part le code online absent je suis très satisfait de allegro!

Bha, pour l'instant je me concentre sur l'apprentissage du C++ par Allegro, et quand je vois du code internet, ça me fais vomir.
Je passerais plus tard peut être sur SFML !

Mais oui, pour une "vielle" lib, elle est très rapide je trouve ! (Plus que XNA + C# !)