C'est un classique. C'est pour ce genre de soucis que les gens preferent les constantes aux #define. Il y a tout un tas de regle a respecter pour eviter oes orobkemes de preprocesseur.

Bunyan, je comprends ta frustration

godrik -> Ok ok Dans la version finale du programme ça sera une variable en fait, car c'est celui qui créera les cartes qui choisiras la taille des maps créées

C'est vrai que je n'aurais pas eu ce problème avec une constante...

^^

Demaine je passe mes TPE de 1ere S. Je stresse à fond .
C'est sur arduino et un shield Ethernet.

bonne chance

en général ça se passe bien

cout<<"blabla"<<endl;

printf

Mais bon tout de même si le C est considéré comme langage de base ...

Bonsoir !

Je voudrais votre avis sur ma fonction d'allocation de mémoire pour un pointeur de pointeur de char, en C :

http://pastebin.com/MCpy7rm0

Vous la trouvez trop longue ? Je me demande si je ne dois pas le subdiviser en plus petites fonctions.

Merci

Ce que je n'aime pas dans ton code c'est que la fonction peut se terminer à plusieurs endroits (plusieurs return, c'est en général signe d'une programmation pas très structurée, enfin de mon opinion perso, j'aime avoir un seul return, ce qui est la preuve que quoi qu'il arrive on atteind bien un certain point de la fonction)
le "continue" ne me plait pas non plus (j'aime pas les break ou continue comme ça qui donnent l'impression qu'on ne sait pas comment structurer les choses)

TU pourrais changer ton :

" if((mapData[x] = malloc(YSIZE * sizeof(**mapData))) != NULL)
{
continue;
}
else
{"

en :

" if((mapData[x] = malloc(YSIZE * sizeof(**mapData))) == NULL)
{
"

ce qui exprime la même chose je crois

Une complexité cyclomatique de 6 c'est raisonnable, une imbrication de 6 c'est limite. Moi la structure ne me gêne pas, mais je n'aime pas reporter la gestion d'erreur 3km plus loin en imbriquant le tout. Un bon (ou mauvais?) exemple de ce qu'on risque avec ça, c'est le premier code sur cette page:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb776913(v=vs.85).aspx

Je trouve ça beaucoup plus compréhensible d'avoir une gestion d'erreur localisée et d'avorter l'exécution de la fonction.

Mouais, je n'aime pas trop les codes avec des tonnes de boucles imbriquées et quelques return, continue, break dans certaines conditions... y a rien de pire à tester, et à maintenir....

Silvermo, comment ferais tu sans mettre plusieurs return ? Car le but est de pouvoir vérifier extérieurement si il y a eu une erreur ou pas J'ai donc besoin d'avoir soit NULL, soit mapData.

Par contre je suis d'accord avec toi sur le continue, j'avais écrit comme tu le met "== NULL", j'ai juste voulu tester autre chose, histoire de voir si c'est plus clair à la relecture ou pas.

Mjonir, merci, je vais regarder ton lien

VampireGirl -> Non mais les détails du lien on s'en fout (enfin, sauf si le sujet t'intéresse, mais c'pas la question). Ce qui est effrayant sur cette page, c'est le premier exemple de code ^^'

Perso, j'aurai plutôt tendance à faire ça :
http://pastebin.com/pFBdXTGt (je vais arrêter, c'est la 4ème version que je minimise...)
Et encore, je sortirai toute la libération de mapData en fonction, mais vu que je n'ai pas fait de C depuis 3 ans et que j'ai la flemme de chercher la syntaxe des paramètres...

Je ne saisis pas pourquoi tu contrôles si x est positif. D'ailleurs, en y regardant de près, si x vaut une valeur négative... tu devrais avoir une segfault (ou équivalent), non ? Vu que tu tenterai d'accéder à une case à indice négatif dans le "else" de la libération.
A minima, le else fait une partie du if et les 3 dernières instructions "free + mapData = NULL + return NULL" peuvent être sorties du bloc if/else et misent à la suite vu qu'exécuter dans tout les cas.

Bunyan -> Je controle si x est strictement supérieur à 0, car si le pointeur numéro 0 a posé problème, faire : x-- poseras problème car là j'effectuerai des opérations sur un pointeur qui n'existe pas

Je vais regarder ton code

Mjonir, j'avoue c'est long et dur à lire, je ne veux pas faire ce genre de code justement :/

Merci, je viens de voir grâce à toi une bonne façon pour supprimer tous ces return :oui Je n'avais pas pensé à ça

Vrai, j'avais zappé ce point, honte sur moi x)

Dans ce cas-là, je corrige :
http://pastebin.com/kte0tD8Z

VampireGirl : tu vois que les return peuvent être réduits au nombre minimum (best practice ^^ )

Ca, ça dépend des cas.

Typiquement, sur des contrôles lourd ou des méthodes longues difficilement découpables, il vaut mieux utiliser les return dès le contrôle (soit proche du début) et faire "deux points" de sortie (entre guillemets car l'idée ici est plus "endroit de sortie" que "point" au sens strict du terme).

La lisibilité en pâti sinon clairement : se trimbaler un code erreur ou encapsuler chaque action dans un bloc "if".

Généralement, il vaut mieux tenter de les réduire, histoire que le flux soit plus facile à voir et contrôler, malheureusement, ce n'est pas possible tout le temps. Ici, clairement, la fonction est courte et facilement factorisable, de même que les comportements.

Oui à fond, ici je suis occupée à réécrire mes autres fonctions. Vous me conseillez de manière générale de toujours avoir un seul return ?

Car par exemple j'avais cette fonction qui ferme un fichier :

http://pastebin.com/3MfiTH0u

Du coup j'ai réécrit la même comme ça :

http://pastebin.com/2SYcF17W

Pour le C, vu que c'est typique de faire des affectation en tant que condition, je serai prudent.

Le principal est la lisibilité. Du moment que c'est facile à lire et ne prête pas à confusion : oui.
Si ça complexifie le code, ou le rend plus compliqué à comprendre "facilement", alors non...

Le problème étant que c'est entièrement subjectif.