Le 24 novembre 2017 à 21:23:53 Zanaki a écrit :
J'aime bien cette idée. Ça ne te dérange pas que je m'inspire sur tout se que tu nous a envoyer ??
Je te dis encore une fois un grand merci pour le temps que tu m'as donner. Parce que mine de rien, c'est du boulot tout ça.

Fais-toi plaisir.

Tester le retour d'une fonction ?
Certaines fonctions peuvent échouer. Par exemple si tu débranches ton disque dur et que tu essaies d'écrire dans un fichier ça ne peut pas marcher (bon c'est un cas extrême mais tu vois l'idée, à mon avis tu auras d'autres problèmes ).

Donc elles renvoient un code. En général 0 = pas de problème, sinon pour chaque valeur (par exemple retour = 1) c'est un problème.
Chaque numéro est une erreur particulière, et en connaissant la correspondance tu es capable de savoir laquelle.

Dans l'exemple que je t'ai mis, j'ai testé les retours de fonctions. Par exemple si malloc renvoie NULL, c'est une erreur. Le if la détecte et traite le cas en question.

Pour le '\0', chaque chaîne en C se termine par cette valeur.
En gros si tu as par exemple un fichier qui contient des pseudos :
pseudo1pseudo2pseudo3

Il faut dire comment les différencier, un utilisateur peut très bien s'appeler "pseudo1pseudo2". Pour cela, en C on fait :
pseudo1'\0'pseudo2'\0'pseudo3'\0'

'\0' est un caractère qui dit qu'une chaîne se termine.

Lorsque tu utilises la fonction strlen, elle parcourt ta chaîne jusqu'à ce qu'elle trouve un '\0'. Mais ça peut être assez vicieux si quelqu'un te passe une "chaîne" qui ne finit pas par ce caractère.

Wow dis donc tu t'es investi 49171

Après je sais pas si l'OP aura besoin de tout ça, j'ai plus l'impression qu'il code pour apprendre à programmer, là on dirait carrément une implémentation pour du code qui sera diffusé Mais c'est intéressant, et c'est bien de voir à quel niveau fixer le rigueur, même si je pense que l'OP n'aura pas besoin d'aller jusque là

Tu travailles dans quoi sans indiscrétion ?

Le 24 novembre 2017 à 21:53:28 aAardvark a écrit :
Wow dis donc tu t'es investi 49171

Après je sais pas si l'OP aura besoin de tout ça, j'ai plus l'impression qu'il code pour apprendre à programmer, là on dirait carrément une implémentation pour du code qui sera diffusé

Il manque les tests unitaires (+ fuzzing), la documentation, gérer la licence, le changelog, gérer le makefile et les différentes cibles + du profiling pour les performances; selon moi c'est le plus important.

Mais c'est intéressant, et c'est bien de voir à quel niveau fixer le rigueur, même si je pense que l'OP n'aura pas besoin d'aller jusque là

Tu travailles dans quoi sans indiscrétion ?

Je suis sans activité.

Tu fais quoi, toi ?

ERRATUM : Au fait c'est return AFF_ACCENT_PRTF; au lieu de return AFF_ACCENT_PRINTF;.

Tu fais quoi, toi ?

Je suis censé bientôt commencer à bosser (j'attends qu'on me donne une mission là en fait ), si possible en C embarqué, je sors d'école là.

Mais toi t'as bien bossé quelque part avant, t'as pas appris toutes les méthodes en autodidacte ?

Tests unitaires, c'est juste tester différents types d'entrées en argument, y compris celles non prévues ?

Le 24 novembre 2017 à 23:02:01 aAardvark a écrit :
Je suis censé bientôt commencer à bosser (j'attends qu'on me donne une mission là en fait ), si possible en C embarqué, je sors d'école là.

Mais toi t'as bien bossé quelque part avant, t'as pas appris toutes les méthodes en autodidacte ?

Si. J'ai fait un cursus maths pures à la fac (j'ai juste une licence, j'ai arrêté).
J'aime juste traîner sur stackoverflow et bidouiller les points vicieux du C.

Tests unitaires, c'est juste tester différents types d'entrées en argument, y compris celles non prévues ?

Ouais pour voir si ça crash. Je trouve le développement dirigé par les tests particulièrement élégant (mais long...quoique ? Y'en a qui disent qu'au final ça fait gagner du temps).

Hey salut ! Alors volà, j'ai essayer le code, j'ai fais toutes les modification et quand je lance le programme il m'affiche la phrase qu'il se trouve dans l'erreur;
[Accent] : Le paramètre 'mess' ne doit pas être null."

Dans cette erreur là, j'ai laisser exit(EXIT_FAILURE); au lieu de return NULL;
Parce que sinon, le texte reste afficher ça m'affiche dans chaque phrase "[Accent] : Le paramètre 'mess' ne doit pas être null."

Je pense qu'il doit avoir un problème dans le programme Accent, parce que se message s'affiche dès que je l'utilise. Alors, je ne sais pas si ça vient du code que tu m'as envoyer, ou un conflit avec celui que j'ai déjà.

Je n'ai pas testé le code que je t'ai envoyé, mais en effet je me suis trompé, il faut plutôt mettre :
if(mess == NULL) à la place de if(mess != NULL)

Okay nickel du coup, j'ai fais ça;
if(mess == NULL)
Et
if(retour == NULL)

Serais-tu s'il te plait m'expliquer se petit code;

enum accent_erreur afficher_accent(const char *t)
{
char *c = Accent(t);
if(printf("%s\n", c) < 0)
{
if(fprtf == DEFAUT || fprtf > 2)
free(c);
return AFF_ACCENT_PRTF;
}
free(c);
return fprtf;
}

Je sais que ça permet de faire une fonction automatisée qui s'occupera de libérer la mémoire
Mais, je me pose une question, quand j'écrit une chaine de caractère pour que ça fonctionne comme je le veux, je devrai l'écrire de cette façon;

    const char* tab[] = {(" Phrase 1"), (" phrase 2"),(" Phrase 3")};
// Suivie de;
int c = Choix(tab,3,29,17);

Sachant que toi la chaine de caractère est écrite de cette façon;

char *c = Accent("éèàâêîë");

Je me demande si ça ne posera pas de problème par la suite. Parce que le C qui est dans l'exemple me sert pour les choix que l'utilisateur devra faire. Or ici, il est là pour créer des chaines de caractère.

Enfin, j'espère que tu as compris se que je veux dire.

Le 25 novembre 2017 à 12:39:47 Zanaki a écrit :
Okay nickel du coup, j'ai fais ça;
if(mess == NULL)
Et
if(retour == NULL)

Très bien.

Serais-tu s'il te plait m'expliquer se petit code;

enum accent_erreur afficher_accent(const char *t)

La fonction afficher_accent prend en entrée une chaîne de type char * à convertir et à afficher, et renvoie une valeur de type enum erreur_accent (le enum tu peux éventuellement le virer avec un#define ou un typedef s'il te gène). L'enumération erreur_accent je l'ai définie plus haut : elle vaut DEFAUT (ou 0) lorsqu'il n'y a pas d'erreur. C'est pour ça que dans Accent j'écris que fprtf = DEFAUT; au début. Quand la fonction commence, vu que fprtf est une variable globale il faut s'assurer que sa valeur est correcte. Toutes les autres valeurs de fptf sont des erreurs, je me suis contenté de les numéroter.

if(printf("%s\n", c) < 0)

De plus printf peut échouer donc je le teste. Toujours tester.

if(fprtf == DEFAUT || fprtf > 2)
free(c);
return AFF_ACCENT_PRTF;

Sauf que voilà, il peut se produire le cas suivant : printf échoue mais peut-être que Accent a alloué de la mémoire. Ça se produit si fprtf = DEFAUT (pas d'erreur), OU (très important, il s'écrit ||) si Accent est allé suffisamment loin dans son code pour allouer dynamiquement mais a échoué. Ça correspond au cas 3 (donc pour fprtf > 2). En relisant c'est vrai qu'on peut simplifier en remplaçant toute la condition par if(c != NULL), pour savoir si tout simplement de la mémoire a été allouée; ce que je te conseille de faire.

Je me demande si ça ne posera pas de problème par la suite. Parce que le C qui est dans l'exemple me sert pour les choix que l'utilisateur devra faire. Or ici, il est là pour créer des chaines de caractère.

Enfin, j'espère que tu as compris se que je veux dire.

Ça s'appelle la portée d'une variable. Je t'invite à chercher sur Internet dessus, c'est assez long à expliquer correctement.
Réponse courte : aucun problème car ce n'est pas le même bloc de données.