Bien quitter son programme

Sauf que ce genre de méthode a programmé n'est guère efficace et peut être de donner impression que ça peut être avantageux , mais clairement pas.

Bktero a dit je que je pensais il faut mieux faire des fonction inline.

Citation:

---

Pour moi, NULL sert surtout à éviter de faire

---

le C selon Neckara ? :aie:

Citation:

---

Le but d'un tel code est d'être mis en début et en fin de fonction.
Il n'est donc pas fait pour être présent deux fois dans une fonction, après, c'est une chose à documenter etc.
Ensuite, je ne donne qu'un exemple, on peut très bien ajouter un deuxième argument pour donner un nom de variable unique et donc passer cette limitation.

Une bonne solution serait d'utiliser des listes chaînée mais il faudrait allouer les maillons .

---

Je que je vois surtout c'est du code peu lisible et peu maintenable.

Citation:

---

Non, il n'a pas à le savoir.
Il sait juste qu'il "réserve" X allocations.
Il fait X allocation puis il "libère" en fin de fonction et c'est tout.
Il copie/colle en début et en fin de fonction, il utilise Malloc() au lieu de malloc(), j'ai pas plus simple.

Après, l'avantage des #define, c'est que ce genre de code est censé être utilisé de partout. Il est inconcevable de copier coller plusieurs lignes dans toutes les fonctions. Ceci sera bien plus maintenable que de corriger 5/6 lignes par fichiers

---

Et il est sensé le deviné peut être ? genre "debutAlloc(SIZE)" a part lire ta déclaration y a vraiment aucun moyen de savoir ce qu'il fait réellement.
Après si t'appelle changer des ligne condensé un gain de temps , on doit pas avoir le même avis sur coder plus vite.
ça va etre un peu prétentieux mais disons que j'ai roulé ma bosse avec le C et je suis par nature pragmatique et ce genre de méthode est peu efficace par contre une méthode plus orienté procédurale/fonction couplé avec des structure est réellement bcp plus efficace ,lisible et maintenable.
Donc vu qu'on est la pour conseillé , autant pas conseillé des méthodes mauvaise parce que oui abus des defines rend le code méconnaissable , on peut même s'amuser a écrire dans une syntaxe d'un autre langage (grâce au define) mais ce genre écriture est proscrire en fait du C pas autre chose.

Citation:

---

Envoyé par Sve@r

Ok, c'est réglé je suis complètement dépassé...:calim2:

---

Bah pareil, j'ai même pas compris pourquoi il faudrait allouer la mémoire autrement.

Citation:

---

Envoyé par Kannagi

Sauf que ce genre de méthode a programmé n'est guère efficace et peut être de donner impression que ça peut être avantageux , mais clairement pas.

Bktero a dit je que je pensais il faut mieux faire des fonction inline.

---

Oui, je n'y avait pas pensé, vous n'allez quand même pas me le reprocher pendant 10 posts non plus :aie:.

Code:

---

le C selon Neckara ? :aie:

---

....

Code:

---

Je que je vois surtout c'est du code peu lisible et peu maintenable.

---

Peu maintenable ?
Mettre 3 define ou 3 fonctions inlines est, quoi que tu puisse dire, infiniment plus maintenable que de mettre de devoir à chaque modification rechercher dans 500 fichiers es fonctions qui utilise cette "méthode" et de les modifier.

Peu lisible ? Pour qui ?
Pour celui qui est censé maintenir la bibliothèque, ce genre de code ne devrait pas lui poser de problèmes. Et puis en cas de doute, gcc -E :roll:

Et puis bon, lire le code d'un #define, c'est pas la mort :

Code:

---

1 2 3 4 5

#define X( ARG, TOTO) fsfsf \ dfsfsdffs \ fsfsdfsdff ARG   X(1, 2)

---

Tu remplace le X(1,2) par le code de ton define soit :

Code:

---

1 2 3

fsfsf \ dfsfsdffs \ fsfsdfsdff ARG

---

Tu enlèves les \ en fin de ligne :

Code:

---

1 2 3

fsfsf dfsfsdffs fsfsdfsdff ARG

---

Tu remplaces ARG par le premier argument donné à X soit 1 et TOTO par le second soit 2 :

Code:

---

1 2 3

fsfsf dfsfsdffs fsfsdfsdff 1

---

Et voilà ;)
C'est presque la même chose qu'une fonction, il y a juste '\' en fin de ligne.

Citation:

---

Et il est sensé le deviné peut être ? genre "debutAlloc(SIZE)" a part lire ta déclaration y a vraiment aucun moyen de savoir ce qu'il fait réellement.

---

Tu lis le code à chaque fois que tu veux utiliser une fonction de la libc ??
Pour un exemple, une idée, tu penses que je vais passer 15 minutes à chercher le nom le plus explicite possible alors que j'ai d'autres choses à faire ??
Si on a inventé les documentations, ce n'est pas pour rien non-plus ;)

Citation:

---

Après si t'appelle changer des ligne condensé un gain de temps , on doit pas avoir le même avis sur coder plus vite.

---

C'est ce qu'on appelle éviter la duplication de code.
Les lignes de codes ne sont pas condensées, elles sont juste ailleurs.

Citation:

---

ça va etre un peu prétentieux mais disons que j'ai roulé ma bosse avec le C et je suis par nature pragmatique et ce genre de méthode est peu efficace par contre une méthode plus orienté procédurale/fonction couplé avec des structure est réellement bcp plus efficace ,lisible et maintenable.

---

Parce que ça :

Code:

---

1 2 3 4 5 6

PreparerMemoire(NB_ALLOC_MAX /*, NOM_ALLOCATION */);   int * foo = (int *) Malloc(sizeof(int) );   LibererMemoire(/* NOM_ALLOCATION */); // en commentaire, la version si on veut "préparer" plusieurs fois la mémoire dans une fonction.

---

ou ça :

Code:

---

1 2 3 4 5 6 7

void * tab = initMemoire(taille) ; // par contre, on risque de devoir faire un malloc, c'est peut être pour cela que je n'ai pas pensé à utilisé des fonctions inlines.   unsigned i = 0;   int * foo = mon_malloc(sizeof(int), tab, &i);   libérerMemoire(tab, taille);

---

C'est pas lisible ?
Je ne sais pas ce qu'il te faut alors.

Tu as déjà regardé, ne serait-ce qu'une fois le code de la libc ou de la stl?
Tu penses que c'est vraiment lisible ? Pourtant cela ne t'empêche pas de pouvoir utiliser les fonctions simplement pour produire un code très lisible.


@dafpp :
En fait, si tu ne libère ta mémoire qu'à la fin, faire :

Code:

---

1 2 3

free(m1); free(m2); free(m3);

---

Est une pratique très mauvaise car il te faudra ajouter/retirer une ligne à chaque modifications.
Et si tu fais 20 allocations ? Ou 50?
Dans ce cas là, il vaut mieux utiliser un tableau :
- donc initialiser le tableau pour que chaque élément vaille NULL ;
- lors d'un malloc, mettre le résultat dans le tableau ;
- et à la fin, parcourir le tableau pour libérer toute la mémoire.

Les #define ou les fonctions inlines, ne servent qu'à rendre le code plus lisible et à éviter de copier/coller tes lignes dans chaque fonctions.

Citation:

---

Envoyé par Neckara

Oui, je n'y avait pas pensé, vous n'allez quand même pas me le reprocher pendant 10 posts non plus :aie:.

---

Et après-tout, pourquoi pas ? C'est tellement rare quand tu sors une ânerie que quand tu la sors, autant en profiter un maximum non ???:mrgreen:

Citation:

---

Envoyé par Neckara

En fait, si tu ne libère ta mémoire qu'à la fin, faire :

Code:

---

1 2 3

free(m1); free(m2); free(m3);

---

Est une pratique très mauvaise car il te faudra ajouter/retirer une ligne à chaque modifications.

---

Bah, char *m[3] puis for (i=0; i < 3; i++) free(m[i]) :P

Citation:

---

Envoyé par Neckara

Et si tu fais 20 allocations ? Ou 50?
Dans ce cas là, il vaut mieux utiliser un tableau :
- donc initialiser le tableau pour que chaque élément vaille NULL ;
- lors d'un malloc, mettre le résultat dans le tableau ;
- et à la fin, parcourir le tableau pour libérer toute la mémoire.

Les #define ou les fonctions inlines, ne servent qu'à rendre le code plus lisible et à éviter de copier/coller tes lignes dans chaque fonctions.

---

Hum, 20 ou 50 allocations ??? De mon coté j'ai beau fouiller dans ma mémoire, en dehors des listes chainées je ne me souviens pas avoir fait des masses de malloc() dans mes différents projets. J'ai déjà alloué un buffer grossissant mais dans ce cas c'est un seul malloc puis du realloc (en réalité c'est que du realloc puisqu'il se comporte comme un malloc lors d'un premier appel) puis un seul free. J'ai déjà utilisé du buffer de taille peu prévisible mais dans ce cas je fais un #define SZ_BUF puis un char buffer[SZ_BUF + 1]. C'est pas aussi propre que du malloc(taille_nécessaire) mais c'est plus simple et ça couvre la très grande majorité des cas. Et même les listes chainées même s'il y a beaucoup d'allocation finalement c'est un seul malloc à la création du maillon...
Donc déjà un malloc on va admettre que ça peut arriver. Deux malloc ça devient un peu plus rare. Alors 20 ou 50...
Bref je pense que ta macro est en effet au mieux un peu démesurée par rapport au besoin.
Surtout que je l'ai un peu relue

Code:

---

#define debutAlloc(SIZE) unsigned int alloc_it = 0; unsigned int alloc_max ; void * alloc[alloc_max = (SIZE)] = {NULL}

---

J'ai pas super bien compris mais il me semble qu'elle définit des variables globales alloc_it et alloc_max. Sans vouloir juger de l'opportunité des globales, que se passe-t-il en cas de projet sur plusieurs sources avec ta macro debutAlloc() dans chaque source ? Il n'y a pas de conflit à l'édition de liens ???

PS: j'aimerais qu'on ne parle pas de inline ici car on est en C et pas en C++...

Citation:

---

Et après-tout, pourquoi pas ? C'est tellement rare quand tu sors une ânerie que quand tu la sors, autant en profiter un maximum non ???

---

C'est si rare que ça ? :oops:

Citation:

---

Envoyé par Sve@r

J'ai pas super bien compris mais il me semble qu'elle définit des variables globales alloc_it et alloc_max. Sans vouloir juger de l'opportunité des globales, que se passe-t-il en cas de projet sur plusieurs sources avec ta macro debutAlloc() dans chaque source ? Il n'y a pas de conflit à l'édition de liens ???

---

Les variables sont locales au bloc où tu utilises la macro d'initialisation (ici debutAlloc(SIZE)).

Citation:

---

Hum, 20 ou 50 allocations ??? De mon coté j'ai beau fouiller dans ma mémoire, en dehors des listes chainées je ne me souviens pas avoir fait des masses de malloc() dans mes différents projets.

---

Une liste chaînée pourrait en effet utiliser beaucoup d'allocations.
On a aussi les très grands tableaux à 2D (allouer que deux blocs ferait allouer un bloc bien trop grand).
Après, le but est d'avoir un petit truc simple d'utilisation et générique utilisable quand on sait d'avance le nombre d'allocation maximale qui sera fait.

Sinon, je suis en train de réfléchir à quelque chose comme :

Code:

---

1 2 3 4 5 6 7 8 9

ManagerFunction( int, foo, int * data \, char * data2 )   { int * data = Malloc(toto); char * data2 = Malloc(titi); return 1; }

---

Mais il faudrait que je trouve le moyen de faire passer int * data \, char * data2 comme un unique argument pour la macro.

Ensuite, c'est assez trivial, on aura, grâce à la macro, une fonction int foo(int * data, char * data2) qui exécutera le code ci-dessous.
A chaque Malloc() on enregistre l'adresse dans une structure adaptée pour (Tas trié sous forme de tableau ?).
Et lorsque la fonction retourne, on libère tout.
Impossible alors de faire des fuites mémoire \o/.
Par contre, il faudra lors d'un Free() retirer l'adresse du tableau pour éviter les doubles libérations de la mémoire :?

Ce qui est sûr en revanche, c'est qu'on pourra forcer l'exécution de code avant et après la fonction foo ce qui peut être plus qu'utile pour :
- faire des logs activables/désactivables pour suivre les appels de fonctions à récupérer quand l'utilisateur voit un plantage du programme.
- faire des fonctions dont on sera sûr quelle ne sera pas lancée deux fois en même temps (avec des mutex).
- autre ?

Citation:

---

PS: j'aimerais qu'on ne parle pas de inline ici car on est en C et pas en C++...

---

Les fonctions inlines existent en C11 il me semble.

inline est un mot-clé du langage depuis (au moins) C99. Voir n1256, section 6.7.4 Function specifiers.

Par contre, je m'aperçois que tu déclares des variables dans tes macros. Je ne suis pas certain à la lecture de cette section de la norme que tu puisses le faire dans une fonction inline. En revanche, plutôt que de de faire un malloc() / free() dans la même fonction, on peut faire un VLA si la taille n'est pas trop importante.

Citation:

---

Envoyé par Neckara

Les fonctions inlines existent en C11 il me semble.

---

En parlant de ça, je ne vois pas (plus) de tuto sur dvp parlant de C11.

@Neckara:
Je ne comprends toujours pas pourquoi il faudrait allouer différemment. Je dois mal comprendre ton idée.

Code:

---

1 2	#define Malloc(Z) ( alloc_it < alloc_max ? ( alloc[alloc_it++] = malloc(Z) ) : NULL ) #define debutAlloc(SIZE) unsigned int alloc_it = 0; unsigned int alloc_max ; void * alloc[alloc_max = (SIZE)] = {NULL}

---

Alors pour toi ce n'est pas du code condensé ? et c'est super lisible de tout mettre sur une seule ligne :roll:

Citation:

---

Et si tu fais 20 allocations ? Ou 50?
Dans ce cas là, il vaut mieux utiliser un tableau :
- donc initialiser le tableau pour que chaque élément vaille NULL ;
- lors d'un malloc, mettre le résultat dans le tableau ;
- et à la fin, parcourir le tableau pour libérer toute la mémoire.

---

J'ai fait un rpg 3D coder de A a Z quasiment , jamais fais de 20 ou 50 free comme tu l'as fait , de plus il y a des for pour pouvoir libérer des tableaux , ou des fonction qui libère plusieurs free pour les structure.

Code:

---

1 2 3 4 5 6 7

void * tab = initMemoire(taille) ; // par contre, on risque de devoir faire un malloc, c'est peut être pour cela que je n'ai pas pensé à utilisé des fonctions inlines.   unsigned i = 0;   int * foo = mon_malloc(sizeof(int), tab, &i);   libérerMemoire(tab, taille);

---

Tres mauvaise pratique ,la tu refait le C avec des defines , c'est ni le but de defines , ni sa compréhension , je me pose juste la question pourquoi ne pas avoir fait tout simplement du malloc/free.
Et d'ailleurs j'ai intérêt de regarder ta définition parque 1) tu déclare tes variable dans tes defines donc je ne peux pas déclarer certaine variable et je ne peux pas l'utiliser 2 fois 2)tu fous du code j'ai pas a quoi je m'attend quand j'utilise un define , surtout que c'est super trompeur mon_malloc(sizeof(int), tab, &i); ressemble a une fonction et ça ne l'est pas donc si par intuition je l'aurais cherché je l'aurais pas trouvé facilement (je regarde pas la .h pour trouver une fonction).
Du coup utiliser une fonction + structure me semble plus indiqué tous simplement que c'est le prog qui déclare ces variable et appelle des fonction , et donc les souci d'en haut disparaisse.

NT: Je viens de mettre un game.c juste pour montrer quel doit être le résultat avec de bonne pratique du C , une ensemble de fonction imbriqué et de structure.
Ce n'est pas le meilleur code que j'ai pondu et y a qql truc a améliorer mais il n'est pas fini.

Citation:

---

Envoyé par Kannagi

Code:

---

1 2	#define Malloc(Z) ( alloc_it < alloc_max ? ( alloc[alloc_it++] = malloc(Z) ) : NULL ) #define debutAlloc(SIZE) unsigned int alloc_it = 0; unsigned int alloc_max ; void * alloc[alloc_max = (SIZE)] = {NULL}

---

Alors pour toi ce n'est pas du code condensé ? et c'est super lisible de tout mettre sur une seule ligne :roll:

---

Je donne une idée en 2 minutes, après c'est si dur de rajouter quelques retours à la ligne :

Code:

---

1 2 3 4 5 6 7 8

#define Malloc(Z) ( alloc_it < alloc_max ? \   ( alloc[alloc_it++] = malloc(Z) ) \   : NULL \   ) #define debutAlloc(SIZE) \   unsigned int alloc_it = 0;\   unsigned int alloc_max ;\   void * alloc[alloc_max = (SIZE)] = {NULL}

---

:roll:

Citation:

---

J'ai fait un rpg 3D coder de A a Z quasiment , jamais fais de 20 ou 50 free comme tu l'as fait , de plus il y a des for pour pouvoir libérer des tableaux , ou des fonction qui libère plusieurs free pour les structure.

---

Qui dit que j'ai fait 20 à 50 free :koi:
Je propose et cherche une piste pour avoir quelque chose de générique qui permettrait d'éviter d'oublier un free et qui faciliterait au maximum l'utilisation de l'allocation/désallocation.

Citation:

---

Tres mauvaise pratique ,la tu réfait le C aved des defines , c'est ni le but de defines , ni sa compréhension , je me pose juste la question pourquoi ne pas avoir fait tout simplement du malloc/free.

---

Encapsulation tout simplement.
Ensuite, tu regarderas comment est codé putchar (c'est une macro normalement).
Non apparement, ce n'est pas putchar, je ne sais même plus quelle "fonction" était une macro :aie:

Sinon pour le cas des "fonctions" min et max, c'est très souvent des macro.

Citation:

---

Et d'ailleurs j'ai intérêt de regarder ta définition parque 1) tu déclare tes variable dans tes defines donc je ne peux pas declarer certaine variable et je ne peux pas l'utiliser 2 fois

---

:roll:
Trop dur de mettre le nom de la variable à ___mylib_compteur_perso.
Et de documenter cela comme une note dans la doc.

Citation:

---

2)tu fous du code j'ai pas a quoi je m'attend quand j'utilise un define , surtout que c'est super trompeur mon_malloc(sizeof(int), tab, &i); ressemble a une fonction et ça ne l'est pas donc si par intuition je l'aurais cherché je l'aurais pas trouvé facilement (je regarde pas la .h pour trouver une fonction).

---

:roll: Là c'était l'exemple avec les fonctions inlines pour reprendre l'idée de Bktero.

De plus, faire passer une macro pour une fonction est assez fréquent, il faut juste respecter quelques précautions comme (pour une "fonction" retournant "void" ) :

Code:

---

1 2 3 4

#define T(ARG) \ do { \   (ARG) + 2; \ } while(0)

---

Sinon, tu es censé rechercher dans la doc et même si c'était une macro, tu l'aurais trouvée facilement.
Par contre, si tu ne regardes ni les .h ni la doc, c'est que tu dois regarder les .c ? :aie:

Citation:

---

Je viens de mettre un game.c juste pour montrer quel doit être le résultat avec de bonne pratique du C , une ensemble de fonction imbriqué et de structure.

---

Je suis assez surpris dès les premières lignes "avec bonne pratique du C" :
- chiffres en dur ("nombres magiques") dans le code ;
- une fonction de 234 lignes ;
- attention à l’indentation.

Ensuite tu te places dans un cas particulier où tu peux regrouper tes variables au sein de structures cohérentes mais-ce toujours possible?

Citation:

---

Je propose et cherche une piste pour avoir quelque chose de générique qui permettrait d'éviter d'oublier un free et qui faciliterait au maximum l'utilisation de l'allocation/désallocation.

---

Est ça pose un souci l'allocation/désallocation ?

Citation:

---

Trop dur de mettre le nom de la variable à ___mylib_compteur_perso.
Et de documenter cela comme une note dans la doc.

---

Ouaw belle résolution du probleme , pas ma façon de coder.

Citation:

---

Sinon, tu es censé rechercher dans la doc et même si c'était une macro, tu l'aurais trouvée facilement.
Par contre, si tu ne regardes ni les .h ni la doc, c'est que tu dois regarder les .c ?

---

Il n'y a pas toujours de doc hein si tu prend un code source sur le net , y a pas forcement de doc donc quand je lis un truc comme mon_malloc(arg); je m'attend a une fonction donc je m'attendrai pas a un define et les fonction ce trouve dans les .c en général.

Citation:

---

Ensuite tu te places dans un cas particulier où tu peux regrouper tes variables au sein de structures cohérentes mais-ce toujours possible?

---

J'ai pas codé tous les programmes du monde mais en règle général c'est largement possible.

Code:

---

1 2 3 4

Je suis assez surpris dès les premières lignes "avec bonne pratique du C" : - chiffres en dur ("nombres magiques") dans le code ; - une fonction de 234 lignes ; - attention à l’indentation.

---

Mon indentation pose un souci ?Quel ligne je serais curieux ? après chaque if ou while j'indente et tous mes crochets sont alignés difficile de faire mieux =P

Je code pas un petit programme , donc une fonction de 234 c'est pas un souci et c'est pas énorme , d'ailleurs si tu code correctement un loader de fichier obj t'en a autant , pour un loader de bmp , pcx j'en ai 130 de ligne.
Après les ligne ne veulent rien dire j'espace beaucoup entre mes lignes.
C'est très stupide de se limiter a un nombre de ligne pour une fonction , si la fonction doit être longue elle le sera ,si elle est court aussi , j'ai des fonctions de 10 lignes comme de 200 j'en vois pas le probleme.

Il y a pas tant de chiffre magique , beaucoup sont des valeurs initialisations , de vrai/faux ou des valeurs en radiants , longueurs ect , mais je dois avouer que je pourrais mettre quelque define.

Citation:

---

Envoyé par Neckara

Qui dit que j'ai fait 20 à 50 free :koi:

---

Euh tu as toi-même donné cet exemple comme possible pour expliquer qu'on pouvait en oublier...

Citation:

---

Envoyé par Neckara

Je propose et cherche une piste pour avoir quelque chose de générique qui permettrait d'éviter d'oublier un free et qui faciliterait au maximum l'utilisation de l'allocation/désallocation.

---

C'est louable... mais à mon avis ça ne peut pas marcher. Parce que l'allocation se fait au début et la désallocation se fait à la fin et qu'il y a plein de choses entre les deux. Et donc tu es obligé de te souvenir, tout au long de ton travail, de toutes tes allocations pour plus tard. Tout comme tu es opbligé de te souvenir de tout ce qui a été ouvert pour le fermer à la fin. Et donc vouloir remplacer malloc() puis travail puis free() par alloc_init() puis travail puis alloc_close() c'est du pareil au même.
Ceci dit, "toutes tes allocations" ça ne se chiffre généralement pas en dizaines non plus...

Citation:

---

Envoyé par Neckara

Encapsulation tout simplement.
Ensuite, tu regarderas comment est codé putchar (c'est une macro normalement).
Non apparement, ce n'est pas putchar, je ne sais même plus quelle "fonction" était une macro :aie:

---

Je vois ce que tu veux dire. putchar() je sais pas mais les isalpha(), isalnum() etc ce sont bien des macros.

Citation:

---

Envoyé par Neckara

De plus, faire passer une macro pour une fonction est assez fréquent, il faut juste respecter quelques précautions comme (pour une "fonction" retournant "void" ) :

---

Oui ben moi j'aime pas. Je préfère savoir réellement si c'est une macro que j'appelle ou une fonction. ne serait-ce que pour éviter de lui passer un "i++". Enfin je présume que les macros cachées n'utilisent qu'une fois le paramètre qu'on leur passe justement pour éviter ce genre d'effet de bord mais qu'importe, je préfère le savoir.

Citation:

---

Envoyé par Kannagi

Mon indentation pose un souci ?Quel ligne je serais curieux ? après chaque if ou while j'indente et tous mes crochets sont alignés difficile de faire mieux =P

Je code pas un petit programme , donc une fonction de 234 c'est pas un souci et c'est pas énorme , d'ailleurs si tu code correctement un loader de fichier obj t'en a autant , pour un loader de bmp , pcx j'en ai 130 de ligne.

---

Hum, il ne fait pas partie des plus beaux programmes que j'ai pu voir. Presque zéro commentaire ; des variables nommées "t" ou "nm" ; une variable "script" utilisée mais pas déclarée (déjà les globales c'est pas super top mais des globales non déclarées...) ; une initialisation avec (double)800 / (double) 600 (peux pas écrire 800.0/600.0; ou mieux, 1.33333 ???), des calculs sur GLUT_KEY_F1 + 255 (?) ; tu décrémentes alpha de 0.05 avant de regarder s'il est inférieur à 0 pour lui mettre la valeur 1 (peux pas regarder s'il est inférieur à 0.05 pour éviter une soustraction inutile ?) ; des nombres en dur comme ce test si rand() vaut 17 (???) et perso j'aime pas le else après l'accolade mais ça c'est contestable. Bref on peut quand-même pas dire que ton exemple soit une super référence des bonnes pratiques en C...

Citation:

---

Envoyé par Neckara

Ensuite, tu regarderas comment est codé putchar (c'est une macro normalement).
Non apparement, ce n'est pas putchar, je ne sais même plus quelle "fonction" était une macro :aie:

---

putc peut être une macro : http://linux.die.net/man/3/putc ;)

Citation:

---

Envoyé par Kannagi

Est ça pose un souci l'allocation/désallocation ?

---

Non, en fait en C++ on a inventé les pointeurs intelligents pour s'amuser :roll:.

Citation:

---

Il n'y a pas toujours de doc hein si tu prend un code source sur le net , y a pas forcement de doc donc quand je lis un truc comme mon_malloc(arg); je m'attend a une fonction donc je m'attendrai pas a un define et les fonction ce trouve dans les .c en général.

---

Donc il ne faut pas coder de fonctions inlines car tu ne les trouveras pas ?
Généralement, tous les prototypes se trouvent dans un fichier .h
S'il ne s'y trouve pas, c'est que la fonction est locale au fichier où elle est utilisée.

Ensuite, on ne te parles pas des codes que tu trouves sur internet mais du code que tu écris là. Dès que tu met les tag doxygen, il n'y a aucun problème pour trouver la documentation.

Citation:

---

J'ai pas codé tous les programmes du monde mais en règle général c'est largement possible.

---

Et dans les cas où cela ne l'est pas, on fait quoi?

Citation:

---

Mon indentation pose un souci ?Quel ligne je serais curieux ? après chaque if ou while j'indente et tous mes crochets sont alignés difficile de faire mieux =P

---

Lignes : 58, 88, 116, 149.
+ lignes 102-103 peut porter à confusion, il aurait fallu rajouter un saut de ligne.

Citation:

---

Je code pas un petit programme , donc une fonction de 234 c'est pas un souci et c'est pas énorme , d'ailleurs si tu code correctement un loader de fichier obj t'en a autant.
C'est très stupide de se limiter a un nombre de ligne pour une fonction , si la fonction doit être longue elle le sera ,si elle est court aussi , j'ai des fonction de 10 lignes comme de 200 j'en vois pas le probleme.

---

Il ne s'agit pas de limiter le nombre de lignes mais de découper ses fonctions en sous-fonctions cohérentes.
C'est une question de lisibilité et de maintenabilité.

Citation:

---

Envoyé par Sve@r

Euh tu as toi-même donné cet exemple comme possible pour expliquer qu'on pouvait en oublier...

---

Possible mais pas nécessairement que je faisais 50 allocs par fonctions dans mes programmes.

Citation:

---

C'est louable... mais à mon avis ça ne peut pas marcher. Parce que l'allocation se fait au début et la désallocation se fait à la fin et qu'il y a plein de choses entre les deux. Et donc tu es obligé de te souvenir, tout au long de ton travail, de toutes tes allocations pour plus tard. Tout comme tu es opbligé de te souvenir de tout ce qui a été ouvert pour le fermer à la fin. Et donc vouloir remplacer malloc() puis travail puis free() par alloc_init() puis travail puis alloc_close() c'est du pareil au même.
Ceci dit, "toutes tes allocations" ça ne se chiffre généralement pas en dizaines non plus...

---

Pas vraiment car il suffit de faire en sorte que lors d'un free, de mettre la valeur correspondante dans le tableau à NULL.

Là, le seul avantage, c'est qu'on pourra libérer le tout en une seule instruction (donc on ne pourra pas oublier un des free).
Après, il vaudrait mieux regarder du côté de la seconde piste pour libérer la mémoire dès que la fonction retourne quoi qu'il arrive (mais pas sûr que ce soit possible).

Citation:

---

Oui ben moi j'aime pas. Je préfère savoir réellement si c'est une macro que j'appelle ou une fonction. ne serait-ce que pour éviter de lui passer un "i++". Enfin je présume que les macros cachées n'utilisent qu'une fois le paramètre qu'on leur passe justement pour éviter ce genre d'effet de bord mais qu'importe, je préfère le savoir.

---

En effet, dans une macro, il ne doit utiliser le paramètre qu'une seule fois, ce qui limite assez les macro.
Mais tu n'as pas à savoir ce qu'il se cache derrière. C'est le principe d'encapsulation.

Citation:

---

Envoyé par Neckara

Non, en fait en C++ on a inventé les pointeurs intelligents pour s'amuser :roll:.

---

Si tu veux pas gérer la mémoire de manière manuelle c'est pas du coté du C qu'il faut voir.

Citation:

---

Envoyé par Neckara

Donc il ne faut pas coder de fonctions inlines car tu ne les trouveras pas ?
Généralement, tous les prototypes se trouvent dans un fichier .h
S'il ne s'y trouve pas, c'est que la fonction est locale au fichier où elle est utilisée.

Ensuite, on ne te parles pas des codes que tu trouves sur internet mais du code que tu écris là. Dès que tu met les tag doxygen, il n'y a aucun problème pour trouver la documentation.

---

Je dis surtout qu'il faut pas en abuser et dans tes exemple tu abuse de l'utilisation des define.

Citation:

---

Envoyé par Neckara

Et dans les cas où cela ne l'est pas, on fait quoi?

---

Pas ta méthode en tous cas :aie:
Mais pour ma part c'est surtout algorithme et un paradigme qui résoudra ton probleme pas la syntaxe du langage.

Citation:

---

Envoyé par Neckara

Lignes : 58, 88, 116, 149.
+ lignes 102-103 peut porter à confusion, il aurait fallu rajouter un saut de ligne.

---

mais oui pour ce manque indentation mais tu pourra le remarquer que c'est seulement pour les if/else ne possédant q'une instruction et ça m'aide a me relire mais oui je devrais normalement indenter mais j'indente pas obligatoirement pour une instruction (qu'on peut me reprocher).

Citation:

---

Envoyé par Neckara

Il ne s'agit pas de limiter le nombre de lignes mais de découper ses fonctions en sous-fonctions cohérentes.
C'est une question de lisibilité et de maintenabilité.

---

Lisibilité c'est pas ton fort , mais maintenable je m'en inquiète pas je réutilise des fonctions qui date de plusieurs années sur plusieurs de mes projets et indépendamment du jeu 2D ou 3D , même sur d'autre langage (qu'il faut réécrire a cause de la syntaxe mais la logique de la fonction est la même).
Sinon je sais très bien découper mes fonction de manière cohérentes et surement mieux que toi ;)
Si cette fonction a 234 lignes c'est pas par plaisir et pas par négligence.
J'ai déjà testé de faire des fonction juste pour réduire le code (pas des fonctions réutilisable donc mais pour réduire son nombre dans la fonction appelante) , finalement j'ai pas gagné en lisibilité ou maniabilité.

Citation:

---

Envoyé par Kannagi

Si tu veux pas gérer la mémoire de manière manuelle c'est pas du coté du C qu'il faut voir.

---

On peut parfaitement implémenter des GC en C (d'ailleurs, il en existe un intégré, mais pas activé par défaut, au C il me semble).

Citation:

---

Sinon je sais très bien découper mes fonction de manière cohérentes et surement mieux que toi ;)

---

Et d'où tu tiens cette affirmation?

Citation:

---

Envoyé par Kannagi

NT: Je viens de mettre un game.c juste pour montrer quel doit être le résultat avec de bonne pratique du C , une ensemble de fonction imbriqué et de structure.

---

Je vais peut-etre passer pour un chieur, mais tu donnes le baton pour te faire battre en meme temps :

• Tu ne verifies pas que systemest alloue avant d'y acceder --> un appel a cette fonction avec un pointeur NULL va crasher des la premiere ligne.
• Tu melanges le code et les declarations de variable
• Tu as des nombres magiques dans ton code
• Tu definies (au moins) un float dans le while, qui n'est pas utilise. A defaut d'etre supprime, il devrait au moins etre defini avant le while.
• Ton code n'est pas symetrique : tu appelles 3 fonctions "chargement" auxquelles ne correspondent que 2 fonctions free : soit tu en as oublie une, ce qui montre un probleme, soit tes 3 fonctions chargement ne font pas le meme genre de choses, et il serait plus lisible de changer le nommage de chargement_camera.

Citation:

---

Envoyé par Neckara

Et d'où tu tiens cette affirmation?

---

Bon je vais répondre , mais pour ma part je suis pas du genre a dire qu'il y a des génies en info , mais du travail et de expérience.
C'est pas une affirmation a 100% mais presque déjà tu veux essayer de faire je que j’appellerai des test en C avec des defines jamais vu ce genre des techniques et déjà que pour qql ligne je suis sceptique , mais en plus étant quelqu'un de pragmatique montre ce genre de technique sur un gros projet qui est lisible et maintenable.
Le second point si on considère que personne est un génie toi et moi sont au point mais j'ai passé 1 ans ou 2 ans a suivre un conseil qu'un étudiant en doctorat m'avais donné comme conseil qui est que "le but d'une fonction soit le plus indépendant possible " et donc j'ai passé les quelque année suivante a programmé que sur ce principe la jusqu’à je le maitrise et je ne le regrette pas ça a porté ces fruits.
Je peux me trompé mes vu des différentes réaction que j'ai pu voir je pourrais dire que tu ne maitrise pas encore ce principe , en théorie oui après en pratique c'est plus long pour cela que moi il m'a fallu des années.

Citation:

---

Tu ne verifies pas que systemest alloue avant d'y acceder --> un appel a cette fonction avec un pointeur NULL va crasher des la premiere ligne.
Tu melanges le code et les declarations de variable
Tu as des nombres magiques dans ton code
Tu definies (au moins) un float dans le while, qui n'est pas utilise. A defaut d'etre supprime, il devrait au moins etre defini avant le while.
Ton code n'est pas symetrique : tu appelles 3 fonctions "chargement" auxquelles ne correspondent que 2 fonctions free : soit tu en as oublie une, ce qui montre un probleme, soit tes 3 fonctions chargement ne font pas le meme genre de choses, et il serait plus lisible de changer le nommage de chargement_camera.

---

System est juste une structure passé en pointeur , je ne fais pas de déclaration en malloc.
Oui c'est vrai tu as raison les déclaration et variable sont un peu mélangé mais j'avais dit que cette fonction était pas fini et je debug/change beaucoup de chose ,surtout que je déclare en général comme tout le monde au début mes variable.
Pour le chargement caméra il n'alloue rien du tout je devrais plus appeler init_caméra vrai.
Le reste aussi , s'il reste un float j'ai que je compte encore utilisé mais pas encore implémentais :aie:
Mais j'avoue volontiers ce que tu dis et j'en suis bien conscient ^^
Si il y a impression de "donner le baton pour me faire battre" , alors j'ai un peu échoue sur je que je voulais faire passé comme message.

Je voulais surtout montrais imbrication des fonction/structure , et c'est celle la qui me semblait le mieux a montré sachant que les autres fonction que j'ai sont des fonction qui n'appelle aucune autre fonction ou très peu.

Citation:

---

Envoyé par Kannagi

C'est pas une affirmation a 100% mais presque déjà tu veux essayer de faire je que j’appellerai des test en C avec des defines jamais vu ce genre des techniques et déjà que pour qql ligne je suis sceptique , mais en plus étant quelqu'un de pragmatique montre ce genre de technique sur un gros projet qui est lisible et maintenable.

---

Une macro min/max/swap permet de ne définir qu'une seule fois une macro qui fonctionnera pour un grand nombre de types.

Après, ce n'est pas parce que tu n'en n'as jamais vu que ce n'est pas utilisé.

Citation:

---

j'ai passé 1 ans ou 2 ans a suivre un conseil qu'un étudiant en doctorat m'avais donné comme conseil qui est que "le but d'une fonction soit le plus indépendant possible " et donc j'ai passé les quelque année suivante a programmé que sur ce principe la jusqu’à je le maitrise et je ne le regrette pas ça a porté ces fruits.
Je peux me trompé mes vu des différentes réaction que j'ai pu voir je pourrais dire que tu ne maitrise pas encore ce principe , en théorie oui après en pratique c'est plus long pour cela que moi il m'a fallu des années.

---

Sauf que là, ce n'est pas une fonction mais une macro.
Et cela fait bien longtemps que je fais des fonctions "indépendantes".
Mais bon, il y a bien d'autres principes à suivre que juste faire des "fonctions indépendantes" et ce n'est pas parce que tu sais faire des "fonctions indépendantes" que tu sais forcément bien découper des fonctions.

Oui bien sur que il y a des macro , je dis pas que j'en ai jamais vu , mais je doute de leur efficacité pour ma part les macro était très utile en assembleur ,mais en C elle devienne beaucoup plus obsolètes.

Citation:

---

Envoyé par Neckara

Mais bon, il y a bien d'autres principes à suivre que juste faire des "fonctions indépendantes" et ce n'est pas parce que tu sais faire des "fonctions indépendantes" que tu sais forcément bien découper des fonctions.

---

Bien sur mais découper ces fonctions dépend beaucoup plus de algorithme mis en place que d'une pratique (même si ça aide) ,enfin je vois surtout que pour toi fonction trop grande = mauvaise fonction , et c’est absurde ça dépend plus du contexte et le but de la fonction.
Les fonction trop haut niveau seront trop spécifique pour en faire de petite fonction :roll: , au cas ou pour ceux qui se pose la question cette fonction affiche un monde en 3D avec un gameplay minimal (menu , combat , parler au perso ,control de la camera , collision, ect).

Citation:

---

Envoyé par Kannagi

Oui bien sur que il y a des macro , je dis pas que j'en ai jamais vu , mais je doute de leur efficacité pour ma part les macro était très utile en assembleur ,mais en C elle devienne beaucoup plus obsolètes.

---

Les macro obsolètes en C ??
Quand tu as besoins de "pseudo-template", tu es très content d'avoir les macros.
Quand tu veux afficher des informations pour un debug :
- ligne ;
- fichier ;
Tu es très content d'avoir des macros

Quand tu veux prendre en charge la rétro-compatibilité de ton code face à l'évolution des noms de fonctions tu es très content d'avoir des macros.

Quand tu veux modifier ton programmes selon les options passé lors de la compilation, tu es très content d'avoir des macros

Quand tu veux créer un programme portable en utilisant des API spécifique, tu es très content d'avoir des macros.

Bref, ne dit pas n'importe quoi non plus.

Citation:

---

Bien sur mais découper ces fonctions dépend beaucoup plus de algorithme mis en place que d'une pratique (même si ça aide) ,enfin je vois surtout que pour toi fonction trop grande = mauvaise fonction , et c’est absurde ça dépend plus du contexte et le but de la fonction.

---

trop grande.
trop indique un excès, une limite dépassée donc oui c'est forcément, par définition "pas bien".
Une fonction doit faire au maximum (à quelques lignes près) la hauteur de l'écran pour faciliter la lecture.
Quand on a une fonction plus grande, on est sûr à 99% qu'on pouvait faire bien mieux.

Citation:

---

Les fonction trop haut niveau seront trop spécifique pour en faire de petite fonction :roll: , au cas ou pour ceux qui se pose la question cette fonction affiche un monde en 3D avec un gameplay minimal (menu , combat , parler au perso ,control de la camera , collision, ect).

---

NON!
Je pense que d'autres membres du forums sauront bien mieux que moi te l'expliquer mais une fonction doit avoir un but précis et un nom explicite.

Ici ta fonction est "game", que fait-elle ? Le nom n'est pas très explicite.
En découpant correctement le code, il sera bien plus facile d'avoir des noms de fonctions explicites.

Ensuite, qu'est-ce qui est fait dans ta fonction ?
- initialisation de la "SDL" ;
- préparation de "décors" ;
- boucle de jeu
-> récupération des événements ;
-> traitement des événements ;
- libération des ressources ;

En théorie, en parcourant très rapidement ta fonction, on devrait pouvoir voir le schémas ci-dessus. Ensuite, si on a besoin d'aller plus "bas-niveau", entrer dans les détails, on ira regarder le contenu de la fonction chargée d'initialiser la SDL par exemple.

Le code devient alors beaucoup plus explicite et lisible. Le lecteur n'a pas besoin de savoir ce que fait en détail ta fonction pour comprendre ce qu'elle fait.

De plus, le code devient aussi bien plus maintenable.
Les fonctions étant "indépendantes", si jamais tu change le contenu d'une fonction, tout le reste du code en sera bien moins "impacté".

Après, c'est très facile de faire une "fonction indépendante" en mettant tout ton code dans une seule fonction... mais un projet ça peut aller très facilement à 8 000 lignes. Tu ne vas tout de même pas mettre 8 000 lignes dans une seule fonction ??

Après oui, limiter une fonction à 15 lignes c'est ridicule mais c'est tout aussi ridicule que de faire des fonctions de 500 lignes.

Une fonction de 300 lignes, ce n'est pas une fonction "indépendante" mais un ensemble de fonctions plus que "dépendante". ;)