Un peu sévère le CptPingu, mais il a pas tort du tout ^^'
Personnellement ca a tendance aussi a me titiller quand je vois une source relativement basique être publié en "expert".
Je compte même plus les caculettes a deux francs (oui, des francs, ca ne vaut même pas des euros) en mode console et qui sont notée expert alors qu'elle ne peuvent même pas résoudre une expression un chouilla complexe ( ex: "3*15+4-(12/3)"). Ou quand elle le peuvent, le code qui le fait est une atroce succession de if/while imbriqué.
Ca me titille tellement que je vais finir par en poster une qui avec un parseur d'expression, utilisant massivement la stl et les foncteurs, peut être même boost::spirit, boost::phoenix et capable de dessiner les courbes correspondantes à des équation, et je metterai ca en "débutant", juste histoire de faire complètement l'inverse.

M'enfin, au final je sais pas si j'aurais le courage de perdre mon temps a faire ca...

La source ici n'est clairement pas a destination des experts, rien de bien compliqué, des mélanges C et C++, etc...
Au passage, il manque le constructeur par copie et la surcharge de l'opérateur '=', la classe n'est pas fiable en l'état.
Sans constructeurs par copie, le compilo en met un qui fait une copie "brutale" de la mémoire. Et donc il copie les pointeurs plutôt que de ré-allouer.
exemple :
Matrix* m1 = new Matrix(2); // le constructeur fait m_matrix = new double*[2]; etc...
Matrix m2 = *m1; // il y a copie, ca ne refait pas l'allocation
delete m1; // m2::m_matrix pointe sur une zone dés allouée et donc invalide.

Il y a des fopen mais aucun close du fichier, la classe possède un membre m_log jamais utilisé (celui dans le constructeur est local au constructeur et non a la classe, de plus il n'est pas utilisé). Aucune vérification n'est faite sur la réussite de l'ouverture du fichier, des allocations, du respect des bornes des paramètres (par exemple, on peut écrire Matrix* m = new Matrix(-12); ce qui vaudra une belle exception non contrôlée), etc...
En prime, les opération allouent une nouvelle matrice qu'il retournent par pointeur, autrement dit ils transfèrent la propriété a l'appelant qui doit donc impérativement penser à détruire le résultat.

J'ai pas envie de prendre le temps de monter un code pour comparer la vitesse de la STL et de la libc, j'y crois pas une seconde, sauf en mode débug. Mais une fois compilé avec les flag d'optimisation qu'il faut, je veux bien croire qu'il y ai un écart, mais certainement pas un ratio de 1000.
Et ce n'est pas "des habitudes que certains jugent bien", c'est juste ce qu'il faut faire. Le fait est que stdio c'est du C, pas du C++, qu'il soit possible d'appeler du C en C++ n'est pas une raison pour utiliser le C plutôt que le C++. Dans ce cas autant tout faire en C. C'est comme en .Net, on peut appeler du C via du p/invoke, ca veut pas dire qu'on doit s'amuser à utiliser stdio plutôt que System.IO.File.

Bonjour,
Quelques remarques :
- Il faut éviter, pour une question de lisibilité, de nommer la moitié des fonctions en anglais et l'autre en français. En général on évite complètement le français à cause des accents.
- S'arranger pour que les fonctions soient déclarées en les ordonnant au dessus du main c'est assez moyen, on fait plutot un .h dans lequel on met toutes les signatures de méthodes et que l'on inclut.
- Faudrait préciser que le code est Windows Only.
- Utiliser les nombres ASCII plutôt que les lettres c'est pas lisible, tu peux fais printf("%c", 'a'), ca marche tout autant et on voit que qui va être affiché sans avoir a sortir la table ASCII.
- Quand ce sont des caractères non affichables ou qui ne donnent pas le rendu réel hors de la console (par exemple ton caractère 178), préfère un define au nom explicite, ainsi on aura dans le code le nom du define plutôt que "178" qui ne parle absolument pas.
- Faute d'orthographe : distance et non distence.
- L'appel à system(const char*) exécute une commande, ce qui signifie qu'il y a création d'un autre processus, c'est très lourd, donc à éviter si c'est juste pour faire une pause ou effacer l'écran. On peux faire une pause en demandant une saisie de l'utilisateur, effacer la console c'est plus chiant, mais ca se fait, exemple ici : http://www.dreamincode.net/code/snippet921.htm
- Il y a pleins de valeurs en dur dont on a aucune idée de l'origine (je pense notamment à tous les for)
- De ce que j'ai compris (je n'ai pas compilé pour tester), tu as une voiture controlée par le joueur, plus une ennemie et tu as un if avec 9 conditions à la ligne 194, qui gère les collisions. Il aurait été plus judicieux de faire un petit calcul mathématique qui calcule la distance qui sépare les deux voitures et ne faire ainsi qu'une seule condition : la distance est-elle inférieure à X ? (où X est la distance minimum pour éviter la collision). Parce que ca non plus, un if avec tout pleins de conditions, c'est pas très lisible.
- Plutôt que ca : char pres[18]={'M','O','U','S','T','A','K','I','M',' ','M','U','S','T','A','P','H','A'}; tu peux utiliser ca : char* pres = "MOUSTAKIM MUSTAPHA";, ca ne t'empêchera pas d'utilise la syntaxe pres[12] pour avoir le caractère en 13 ième position, tout comme un tableau.

Voila, c'est a peu près tout ^^

J'ai jeté un oeil aux autres codes sources de l'auteur, c'est toujours les mêmes problèmes : illisible, tout le code dans les headers, quasiment aucun commentaire utile.
Il faudrait effectivement ouvrir un livre de C. Ou même d'à peu près n'importe quel langage, car tous disent la même chose : il faut commenter et travailler la lisibilité du code. La seule chose que précisera en plus un livre de C ou C++ c'est qu'on ne met pas le code dans les headers (et deux/trois autres détails tels que ne pas utiliser de goto a moins que ca ne soit véritablement nécessaire, vérifier le retour des fonctions car elles peuvent échouer, éviter d'imbriquer 15 scopes, ...)

- Le code ne compile pas
- Tout le code est dans les headers
- Aucun commentaire ou presque
- Lisibilité quasi nulle, notamment a cause de l'absence de commentaire, il est très complexe de comprendre une expression telle que : "while((A[i]!=43)&&(A[i]!=45)&&(A[i]!=47)&&(A[i]!=42)&&(A[i]!=40)&&(A[i]!=41)&&(A[i]!='^')&&(A[i]!='E')&&(A[i]!='\0'))"

Hum, ouais, pourquoi pas.
Personnellement je n'ai pas le même vocabulaire.

a = 10; //Définition de variable, moi je dis valorisation
int max(int a,int b) { return (a > b)?a:b; } //Définition de fonction, moi j'appel ca "le code" ou "le corps" d'une fonction.

Et, toujours pour moi, une valorisation ca reste du code, ca n'a donc rien a faire dans un .h (encore une fois, y'a des cas où on y peut rien).

Mais bon voila, cette petite différence de vocabulaire n'est pas bien importante.

Oui je suis têtu, mais non je ne cherche pas a te convaincre.
D'autant que j'avais bien compris que tu étais en parti d'accord avec moi. Cependant j'ai préféré complété mon premier poste compte tenu de ta réponse, afin d'être plus clair au vu de tes remarques, sans compter que tu n'es pas le seul lecteur.
Moi je dis définition, déclaration ca me va aussi. Il n'y a pas grandes différences.
Enfin, je vois pas en quoi mon dernier paragraphe est complètement faux. Tu dis que tout mettre dans un .h n'est pas la bonne méthode, tu dis donc la même chose que moi. J'en conclut donc que tu n'es pas d'accord sur le fait que je dise qu'une mauvaise pratique ne se perd pas facilement. Mon expérience m'a toujours montré a quel point les habitudes, bonne ou mauvaise, sont dures à perdre, tu as tout à fait le droit de ne pas être d'accord, comme je l'ai dis, ce n'est que mon avis.  Mais ca ne le rend pas faux pour autant. Bref, je vois vraiment pas en quoi c'est "complètement faux". Et puis je n'ai jamais dit que ce n'était pas compréhensible pour un débutant de faire ainsi, je dis juste qu'il ne faut pas faire comme ca et j'explique comment faire selon moi, j'oblige personne à adhérer, approuver ou je ne sais quoi d'autre.

Le prototype d'une fonction est un des types de définition/déclaration qu'on met dans un fichier .h.
Mais on met également les structures, les enums, les #define, les #typedef, ....
C'est pour ca que j'ai parlé de définitions et non pas de prototype.
Ce découpage n'est pas vraiment pour faire de la pseudo POO bien que faire de la pseudo POO passe par ce découpage.
Il s'applique toujours pour plusieurs raisons :

- beaucoup plus lisible. Puisque qu'un fichier C ne contient que le code d'une partie précise, il n'est pas pollué par le reste. C'est très proche de la notion d'objet, mais c'est pas pour autant que c'est de la POO.

- beaucoup plus facile a maintenir. Le code étant découpé il est plus facile d'opérer des mises à jour sur une portion sans attaquer le reste. Ça évite aussi les fichier .C qui font 250 000 lignes. Ce qui évite d'alourdir inutilement les IDE, les compilos et le cerveau qui doit s'y retrouver dans tout ce foutoir. 250 000 lignes peut paraître un chiffre énorme pour un débutant, mais non, ca vient très très vite. Par exemple, en ce moment au boulot je travail sur un petit utilitaire en C# (langage qui nécessite moins de code que le C ou C++ pour obtenir le même résultat). Ça fait 1 semaine que je bosse dessus, le truc fait déjà 6000 lignes de code. Je pense qu'une fois fini il devrait être dans les 10 000. Tout ca pour un tout petit utilitaire qui prend des données d'une base pour les injecter dans une autre (bon il fait un tout petit peu plus que ca, mais vraiment pas grand chose). Alors imagine un vrai gros projet sur lequel bossent une dizaine de personne.

- réutilisation. Si demain tu décides de séparer ton programme en un .exe et une .dll laquelle contient, par exemple, toute la gestion de l'affichage, ton code restera quasiment inchangé. De même, si tu décide de créer un nouveau programme qui utilise en grande partie ce que tu as déjà fait dans celui-la, tu pourra te contenter d'inclure les fichiers plutôt que de partir dans un copier/coller qui risque plus de tout casser qu'autre chose.

- Moins de problèmes "étranges". En mettant le code dans le .h tu dupliques le code à chaque fois qu'il est inclut, plutôt que de réutiliser le code en question. Dans la DLL tu met un code de gestion de l'affichage (dessins des barres/briques/...) et dans l'exe tu fais des appels à ces fonctions. Donc tu as inclut le fichier H dans les deux, or, le fichier H contient le code, donc ton exe ne fera pas appel à la DLL contrairement à ce que tu pouvais penser, puisqu'il dispose du code 'en local'. Résultat, non seulement tu as une DLL qui sert à rien, mais en plus tu peux être amené a te dire que tu peux mettre à jour le code d'affichage et redistribuer juste la DLL, ce qui aurait été vrai, mais vu que ton exe n'utilise pas la DLL, bah ca marchera pas. Et ce genre de truc, crois moi, tu va galérer comme pas permis pour comprendre d'où vient le problème, parce que le compilo te laissera faire, le debugger ne verra pas le problème et l'exe fonctionnera parfaitement.

- respect des standard. C'est comme ca qu'on doit faire (ca fait parti de la norme du C et du C++), ce n'est pas parce que le compilateur te permet de faire autrement qu'il faut en profiter. A moins de pas avoir le choix, mais vu l'age de la norme, le nombre de cas où on a pas le choix est proche de 0. A la limite, quand tu sais très bien ce que tu fais et que tu maitrise bien les impactes, tu peux te permettre de prendre des libertés sur la norme. Mais quand ca n'a aucun intérêt, je vois pas pourquoi le faire. La norme est la pour faire abstraction d'un paquet de problèmes potentiels.

Je ne suis absolument pas d'accord avec les mauvaises pratiques qui "sont plus simple pour un débutant". Une mauvaise pratique reste une mauvaise pratique, quand on s'y habitue ca devient très dur de s'en défaire. De plus, il a beau être débutant il dit aussi vouloir faire un bilan avant de se mettre au C++. Bah voilà, c'est un bilan, y'a du bon et du mauvais, lui montrer les mauvais points pour qu'il progresses est à mon sens plus utile que de les occulter. Et s'il conserve cette pratique pour se lancer dans le C++ il va droit dans le mur. Enfin ce n'est que mon avis.

Personnellement je trouve le C plus rigoureux dans la séparation des fichiers...
Petit rappel, le .h est un fichier d'entête, il est fait pour contenir les définitions et uniquement les définitions, pas le code.
Le code va toujours dans des fichier .C, .CPP, CXX, ... mais pas dans les fichiers .H (a quelques rares exceptions comme les templates en C++ où la on a guerre le choix, sauf qu'on nomme généralement ces fichiers .HPP).
Le compilateur dira rien si vous ne suivez pas cette règle, lui il s'en tamponne. Cependant, ne pas suivre ces règles ca signifie une maintenance bien galère et la quasi impossibilité de réutiliser le code.
Si tu met ton code dans un .h, à chaque fois que tu inclut le .h, tu inclus le code avec, ca devient donc une seconde instance du même code. Ca implique plein de limitations avec des choses vraiment pas simples a débugger.
Donc définitivement non, le code ne vas pas dans les fichiers .h mais dans les fichiers .c.
C'est pas dur du tout en plus.
Par exemple, ton fichier barre.h, fais-en une copie nommée barre.c, tu vires les gardiens (#ifndef BARRE_H_INCLUDED ...#endif), t fais un include de barre.h dedans. Maintenant tu vas dans ton barre.h, tu supprimes tout le code de la fonction (c'est a dire tout ce qu'il y a entre accolade, accolades incluse) et tu met un ';' à la place : SDL_Rect barre(SDL_Surface *ecran, int* boucle);
Tu ajoutes un include de SDL.h car sinon le fichier n'est pas viable seul (ca compilera peut être si SDL.h est inclut ailleurs, mais la compilation seule de barre.c ne peut fonctionner) et vola, le tour est joué, tu as maintenant un fichier .c contenant le code, compilable et linkable, accompagné d'un fichier .h contenant toutes les infos pour permettre d'utiliser ce code depuis n'importe où.
La séparation en .c/.h n'est pas faite pour séparer la GUI du reste ou je ne sais quoi, mais pour séparer le code des définitions afin de permettre la réutilisation du code.
Le C++ n'automatise absolument pas cette procédure, rien n'empêche de faire de même, c'est juste que les IDE proposent l'ajout de class plutôt que l'ajout de code, ce qui se traduit par l'ajout d'une class modèle pré-décomposée. Ça n'est pas fait en C pour la simple et bonne raison qu'il n'y a pas de classes et donc rien que l'on puisse pré-décomposer.

Bonjour,
Je n'ai pas regardé le code pour le moment mais je peux déjà donner une piste à ta question.
Ce que tu cherche à faire s'appelle la "Stéganographie". Il en existe des dizaines de formes selon ce qui doit être caché et dans quoi (cf. article de wikipédia  http://fr.wikipedia.org/wiki/St%C3%A9ganographie).

Voici une méthode simple pour masquer une donnée dans une image 24 bpp (24 bits par pixel) :
Chaque pixel est composé de 3 octets, un pour le rouge, un pour le vert et un pour le bleu. Ça fait énormément de couleur, bien plus que nos yeux peuvent en distinguer. L'astuce consiste donc a prendre le bit de poids faible de chaque octet pour y stocker un bit de la donnée qu'on souhaite cacher. Ainsi, on dégrade l'image d'origine, mais c'est imperceptible a nos yeux. Attention toute fois, tous les formats ne sont pas compatibles avec cette méthode, par exemple le jpeg ne fonctionne pas car sa compression risque de faire perdre ce bit de données, en revanche, le bmp fonctionne très bien, tout comme le png, qui sont des formats sans pertes.

On remarque que l'inconvénient de la méthode est qu'on ne peut utilisé qu'1/8 du poids de l'image d'origine pour stocker la donnée (puisqu'on utilise un seul bit par pixel). Cependant, rien n'empêche de compresser la données avant de la cacher (même si ca ne fait que repousser le problème).

Il existe évidemment bien d'autres méthodes, je te laisse les chercher si le coeur t'en dit.

En l'occurence sur ce genre d'opération, tous les compilos que j'ai testé détectent s'il va y avoir perte de donnée et te préviennent. Mais je suis d'accord sur le fait qu'il ne faut pas présumer de ce que va coder le compilo, je l'ai fais ainsi parce que j'ai vérifié ce que ca donnais avec le mien, mais comme je le disais également, pour en être véritablement certain, il faut caster, exactement comme tu le montres.