Bonjour à tous,

Vous vous demandez sûrement comment sera codé SDL_SEGED, si non vous allez tout de même le savoir (pour ceux qui ne savent pas ce qu'est SDL_SEGED, http://blog.developpez.com/sdl-seged...-est/#more9918 ou alors http://www.developpez.net/forums/d10...ed-quest-cest/).

Voici tout d'abord le prototype type :

Code : Sélectionner tout - Visualiser dans une fenêtre à part
void m_SDL_.... (entrées de la fonction d'origine, int ligne, char *fichier)
Analysons donc ce prototype, tout d'abord le type de la fonction, vous vous en doutez ce ne sera pas toujours void (j'ai choisi le 'void' au hasard pour le prototype type), ce pourrait être SDL_Surface* ou encore Uint32 (par exemple, pour void on a 'SDL_Init', pour SDL_Surface* on peut avoir 'SDL_LoadBMP' et pour Uint32 'SDL_MapRGB').
Venons en maintenant au nom de la fonction :<code>m_SDL_....</code>, les '...' correspondent au nom de la fonction (je préfère le préciser au cas où ). Mais la fonction ne sera pas appelés comme telle, je vous expliquerai un peu plus loin pourquoi.
Bon les types c'est fait, le nom c'est fait, maintenant viens les entrées. Pour rappel les voici :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
(entrées de la fonction d'origine, int ligne, char *fichier)
Bon les entrées de la fonction d'origine vous comprenez j'imagine, passons donc aux deux autres. Ils correspondent en fait à la ligne et au fichier de la fonction appelante. Je sens que vous ne comprenez pas ... Voici un exemple :

J'apelle la fonction à la ligne 23 du fichier main.c, eh bien ligne aura la valeur '23' et fichier 'main.c' !
C'est bon maintenant ? Ces deux informations nous serviront si jamais il y a une erreur.

Venons en maintenant à la deuxième partie de ce billet, qui sera nettement plus courte que la première, l'appel de la fonction. Vous vous souvenez, je vous avait dit que l'appel de la fonction sera différente du prototype, eh bien si j'ai dit ça ce n'est pas pour vous gêner mais pour vous aider ! Vous savez sûrement comment avoir la ligne et le fichier d'une fonction ? Non ? Qu'à cela ne tienne, voila comment :

Bon vous vous imaginez maintenant écrire à chaque fois ces 2 choses à la fin de vos appels ? Non bien sur ! Et c'est la que les macros interviennent ! Voici tout de suite la macro type :

Code : Sélectionner tout - Visualiser dans une fenêtre à part
#define my_SDL_... (entrées de la fonction d'origine) m_SDL_... (entrées de la fonction d'origine, __LINE__, __FILE__)
Le travail de cette macro est simple, à chaque appel sous la forme 'my_SDL_...(entrées)' il le remplacera par 'm_SDL_...(entrées, __LINE__, __FILE__)' !

Voici maintenant le code de la fonction type :

Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
 {
SDL_Surface* exe = my_SDL_.... ;
suivi_log ("Phrase d'explication", NULL);

   if (exe == code d'erreur)
   {
      erreur_log ("Phrase d'erreur", ligne, fichier, NO_STOP);
   }
return exe;
}
Analysons donc tout ça ... Au début j'intialise une variable de type SDL_Surface*, ça aurait très bien pu être autre chose, comme un int, ou un Uint32, voire meme rien du tout si c'est un void ! Puis on envoie une petite phrase d'explication à la fonction 'suivi_log' qui va la marquer dans le fichier log.txt. Vous avez surement remarquer le 'NULL', eh bien en fait il représente une deuxième chaine, au cas où ce serait une image qui serait chargé. A ce moment là, on remplacerai le 'NULL' par la chaine contenant le nom de l'image qui serait donc automatiquement concaténé à la première chaine puis écrite dans le fichier log.txt .
Viens ensuite la conditon if. On voit qu'elle vérifie si la fonction a renvoyé un code d'erreur, si c'est le cas, onn appelle la fonction 'erreur_log' qui écrira dans le log, à côté du message correspondant à la fonction la phrase que nous lui envoyont, en plus du classique SDL_GetError. Les paramètres de cette fonction sont donc la chaîne à envoyer, mais aussi la ligne et le fichier de la fonction pour savoir où est le problème plsu précisement. Et nous avons un 'No_STOP' qui traine, il correspond au flag qui dit 'Ce programme ne doit pas se fermer lorsqu'une erreur se produit'. En effet si le programme devait se fermer à chaque erreur, ce sera un peu exagéré, donc le programme ne se fermera que si l'erreur est grave (SDL_Init qui renvoie une erreur par exemple). Pour l'instant cette fonctionnalité est 'automatique', c'est à dire que c'est moi qui décide si le programme s'éteint ou pas, mais je pense rajouter quelques **SPOILER** pour vous permettre de le faire vous-mêmes
Puis viens ensuite le return si il y en a besoin, vous imaginez bien que le return de SDL_LoadBMP est très important mais celui de SDL_Init on s'en fout un peu vu que c'est seulement un code d'erreur.
Bon on a fini cette explication de la fonction. Passons maintenant à la structuration du projet.

Le projet sera donc découpé en autant de couple fichier/header qu'il y a de catégories dans la SDL. Il y aura donc un fichier video.c, et son header, un fichier thread.c, et son header .... Ainsi que le header et le fichier qui contiendra les fonctions d'écriture et surement d'autre choses à venir

Voici d'ailleurs la liste :

- general.c/general.h
- video.c/video.h
- window.c/window.h
- event.c/event.h
- joystick.c/joystick.h
- audio.c/audio.h
- cdrom.c/cdrom.h
- thread.c/thread.h
- time.c/time.h

-log.c/log.h
Je pense que tant que je serai seul sur ce projet je commencerai par les fichiers possédant le moins de fonctions

Voila ! J'attends vos commentaires, ressentis ...

Merci,