J'essaie de créer un programme capable d'additionner deux nombres dont la valeur tend vers l'infinie mais qui bien sûr serait aussi capable de faire de simple addition
#include <stdlib.h>
#include <unistd.h>
void my_putchar(char c)
{
write(1, &c, 1);
}
int my_put_nbr(int nb)
{
int a;
if (nb < 0) {
my_putchar('-');
nb = nb * (-1);
}
if (nb >= 10) {
a = nb % 10;
nb = nb / 10;
my_put_nbr(nb);
my_putchar(a + 48);
} else {
my_putchar(nb + 48);
}
return (0);
}
int my_strlen(char const*str)
{
int a;
a = 0;
while (str[a] != 0) {
a = a + 1;
}
return (a);
}
int my_putstr(char const *str)
{
int a = 0;
while (str[a] != '\0') {
my_putchar(str[a]);
a = a + 1;
}
write(1, "\n", 1);
return (0);
}
char *infin_add(char const *s1, char const *s2)
{
int b;
int c;
int d = my_strlen(s1);
int e = my_strlen(s2);
int a;
char *crop;
if (e <= d) {
crop = malloc(sizeof(char) * (d + 2));
a = d - 1;
}
else {
crop = malloc(sizeof(char) * (e + 2));
a = e - 1;
}
while (s1[a] == 0) {
if (s1[a] && s2[a]) {
b = (s1[a] - 48) + (s2[a] - 48);
if (b >= 10) {
b = b - 10;
c = 1;
}
else {
c = 0;
}
crop[a] = b + 48;
a = a - 1;
}
else
b = (s1[a] - 48) + (s2[a] - 48) + c;
if (b >= 10) {
b = b - 10;
c = 1;
}
else {
c = 0;
}
crop[a] = b + 48;
}
}
return (crop);
}
int main(int ac, char **av)
{
my_putstr(infin_add(av[1], av[2]));
return 0;
}
Je n'ai pas d'erreurs de compilation mais le programme ne fonctionne que lorsque la somme des deux nombres est inférieur à 10 et si ils ne sont pas négatifs.
Bonjour ! Si j'ai bien compris, le but est de calculer les additions avec le même algorithme que lorsqu'on pose une addition à la main, c'est bien ça ? Je crois que tu devrais ajouter des commentaires pour nous guider. Je sais que les pros n'aiment pas qu'il y ait trop de commentaires dans les programmes, mais là on est dans un cas particulier : un listing destiné à être montré à des internautes inconnus pour avoir de l'aide. Par exemple j'aimerais bien savoir quelle variable stocke la retenue. 'c' ? C'est quoi 'crop' ? Etc.
J'avais programmé ça il y a quelques années et c'était beaucoup plus compliqué que ce que je croyais au départ (surtout que je manipulais des nombres à virgule, ce que tu ne fais pas je crois). J'avais fait seulement l'addition et la soustraction, j'avais laissé tomber la suite, trop casse-tête pour un passe temps destiné à me délasser... Je me souviens qu'il était essentiel de bien tester chaque étape (donc chaque fonction) une par une. Ne surtout pas tout écrire et seulement alors tester.
Ici, il faut que tu testes les étapes une par une d'abord avec des cas simples. Par exemple 8+8. Fais afficher chaque étape, ainsi tu verras où ça coince. Mais ne reste pas devant le listing sans chercher la cause des erreurs. Ce n'est pas en regardant le listing qu'on trouve des erreurs, surtout quand c'est casse-tête comme ici.
C'est vrai, que ça ne rend pas le code facile à lire.
Il y a un truc qui m'interpelle : C'est la condition de ta boucle while dans la fonctioninfin_add, comment fais-tu pour trouver un caractère valant 0 dans une chaîne de caractère en la parcourant de la fin vers le début ?
> Je sais que les pros n'aiment pas qu'il y ait trop de commentaires dans les programmes,
Il y a eu pendant un certain nombre d'années un bruit qui courait comme quoi il ne fallait pas mettre de commentaires "parce que le code doit être suffisamment clair pour se suffire à lui même".
C'est complètement con comme idée. Le code décrit comment l'ordinateur fera quelque chose, et pas ce que ça fait. Encore moins pourquoi. En fait c'est un truc de fainéant prétentieux qui n'est pas foutu d'expliquer ce qu'il fait.
---
Les "pros" n'aiment pas deux sortes de commentaires
ceux qui n'apprennent rien à ceux qui lisent le code
ceux qui contredisent ce qui se passe
Un exemple de commentaire
i++; // on ajoute 1 à i
le débutant dira que c'est le genre de commentaire que ses profs (ou tutoriels) montrent dans leurs exemples. Mais il faut bien comprendre que ces exemples sont là pour expliquer le langage à ceux qui ne le connaissent pas. Dans la communication, il faut se rappeler qu'un message à un rôle, et un destinataire.
Si c'est pour travailler ensemble sur du code, on suppose que le collègue n'est pas un crétin total, et qu'il connait le langage avec lequel il travaille. Sinon, pourquoi lui passer du code ? Donc commentaire inutile.
Un commentaire utile, ça serait
// retenue si b dépasse 10
Il est inutile que je vous fasse l'article sur les commentaires qui racontent des trucs faux.
Pour en revenir aux commentaires inutiles : ils sont clairement nuisibles, parce qu le rôle d'un commentaire est d'attirer l'attention sur un point qui a besoin d'être commenté. Si il y en a trop, personne ne les lira.
Cas particulier, les commentaires qui servent de documentation, et qui devraient figurer pour chacune des fonctions.
/**
* Retourne la somme de deux nombres.
* les nombres et le résultat sont représentés par
* des chaînes de caractères en décimal
* (avec signe - en tête ?)
* Le résultat est alloué dynamiquement, et doit
* être libéré.
* \param s1 nombre représenté par une chaîne
* \param s2 nombre représenté par une chaîne
* \return une chaîne représentant la somme, ou NULL
* si l'allocation est impossible.
**/
char *infin_add(char const *s1, char const *s2)
Ca fait un peu plus "pro", vous ne trouvez pas ?
- Edité par michelbillaud 17 octobre 2020 à 18:13:36
Merci pour cette synthèse sur les commentaires ! La notation \param et \return, c'est une syntaxe reconnue quelque part ?
Ce que je voulais signaler, aussi, c'est que dans un message destiné à demander de l'aide, je pense qu'il ne faut pas avoir peur de mettre plus de commentaires, y compris des commentaires qui seraient inutiles dans un autre contexte J'y vois deux raisons : 1° faciliter la tâche de ceux qui liront le message ; 2° savoir ce que le posteur croit que son programme va faire.
Exemple de 1° :
// 1) Recherche de la position de la virgule
< diverses instructions, voire un simple appel à une fonction... >
// 2) Alignement des deux tableaux de chiffres sur la virgule
< diverses instructions... >
// 3) Addition des éléments du tableau avec calcul de la retenue
< diverses instructions... >
// Ici le calcul de la retenue :
< diverses instructions... >
Exemple de 2° :
// Mise à zéro des éléments négatifs :
< ici des instructions où tout est mis à zéro : on
en déduit immédiatement que c'est une erreur >
my_putchar permet d'afficher un caractère, elle est utilisée pour coder les fonctions qui interviennent dans le programme à savoir,
my_strlen qui compte et retourne le nombre de caractères d'une chaîne de caractère;
my_putnbr qui permet d'afficher un int comme le ferait la fonction printf;
my_putstr me permet d'afficher une chaîne de caractères;
Maintenant la fonction clée de cet exercice infin_add:
Dans un premier temps je crée une chaîne de caractères que j'appelle crop, crop est un peu comme le résultat de l'équation. Je lui attribue un espace suffisant grâce à malloc qui est égale à l'espace du plus grand nombre entré en paramètre + 2 (+1 au cas ou le résultat aurait un chiffre de plus que le plus grand chiffre entré en paramètre et +1 encore pour rajouter le dernier terme d'une chaine de caractère '\0').
Une fois cela fait, par une série de commandes je réapprend à la machine à faire l'addition je lui dit de placer les résultats de la somme (unité + unité, dizaine + dizaine etc) dans la chaîne de caractères crop en partant de la fin. La variable c est la retenue c'est à dire je fais 6 + 9 =15 j'écris 5 je retiens 1 qu'il faudra ajouter à la prochaine somme et ainsi de suite, c'est justement la variable c qui gère cette condition. Puisque je veux faire des additions infinies ma fonction prend en paramètre des char * et non des int qui ont une limite. Pour convertir les caractères en nombres pour la machine je prends ces derniers et je leur soustrait 48 ( voir table ASCII) que je défini sur le c (qui d'ailleurs est un int ). Par la suite b est comparée à 10, s'il est supérieur ou égale on considère uniquement son chiffre des unités, la retenue est définie sur 1 (c = 1) et le b est placé à la fin de la chaîne de caractère sinon le b est juste placé à la fin de la chaîne. Puisqu'il n'y a pas de retenue pour la somme des chiffes des unités j'ai décider de séparer ce cas (ce n'était pas nécessaire mais bon) c'est pour cela que dans ma boucle for il y a un if et un else (pour la somme du chiffre des unités et ensuite pour les autres chiffres).
Une fois tous les chiffres recueillis et placés dans la chaîne de caractère j'utilise my_putstr dans le main pour afficher cette dernière qui devrait logiquement donner le résultat.
Si tu veux pouvoir additionner des nombres qui tendent vers l'infini alors abandonne. En informatique tous les variables ont une taille en mémoire et la mémoire est finie donc on ne peut pas déclarer de nombre infini ! Chaque nombre a un minimum et un maximum (0 et 255 pour un char par exemple). Si tu veux faire une addition avec des nombres de maximum infini (taille max = taille de la mémoire physique) il faudrait un nombre intelligent qui se divise tout seul en plusieurs sous nombres et je ne pense pas que faire ceci en C de façon transparent pour l'utilisateur soit réalisable. Du C++ serait plus simple avec ce problème.
Si j'avais tu peux essayer avec le int64_t de la lib stdint.h
@BrigitteLPB Je crois bien que tu es hors sujet, c'est un exercice avec un cahier des charges imposé !
rouloude a écrit:
Il y a un truc qui m'interpelle : C'est la condition de ta boucle while dans la fonction infin_add, comment fais-tu pour trouver un caractère valant 0 dans une chaîne de caractère en la parcourant de la fin vers le début ?
Ça ressemble à du code de l'école 42. C'est bourré de choses à ne surtout pas faire, si tu venais à faire du C plus tard, il te faudra tout réapprendre. Quelques exemples: - on ne peut pas préjuger que stdout vaut 1. - on ne peut pas préjuger que le code de '0' est forcément 48. - bravo pour l'utilisation correcte de const, il en manque mais c'est un début - avoir des noms de variable non explicite est une erreur grave, la lisibilité est un des concepts les plus importants dans l'écriture d'un code. - ce que l'on passe à malloc() est un nombre de char, il ne faut pas multiplier par sizeof(char) bien que sa définition soit bien le nombre 1. - ne pas mettre de parenthèses lors d'un return. - on doit déclarer les variables au plus près de leur utilisation et non pas en début de fonction. - on doit préinitialiser les variables à moins d'avoir une très bonne raison de ne pas le faire. - toujours préférer un for à while quand on itère sur un indice, il est beaucoup plus lisible. - j'en oublie d'autres...
Pour revenir à ton objectif: - si un code a des malloc(), il devrait aussi avoir les free() correspondant. - bien vu le +2 lors de ton malloc() tu as donc bien préanalysé ton problème. - attention si tes 2 nombres n'ont pas le même nombre de chiffres, la variable "bien nommée" ane peut pas à la fois indiquer la position du chiffre à ajouter pour les 2 nombres! De là découlent tous les cas avec des longueurs différentes qui ne peuvent pas fonctionner. - les (s1[a] == 0) et (s1[a] && s2[a]) n'ont pas de sens ce que tu traites ce sont des caractères de '0' à '9', il ne sont donc jamais nuls. - ligne 53, la retenue, for "bien nommée" cn'est pas initialisée. - ligne 68, avec ce while qui devrait être toujours faux, peu de chance que ton code fournisse un quelconque résultat. - ligne 70, il manque l'ajout de la retenue. - il faut prévoir le cas où tu ajoutes un chiffre à rien de correspondant dans l'autre nombre. - si à la fin, il te reste une retenue c'est qu'il faut ajouter un '1' devant le nombre - ne pas confondre le début de ton buffer le "bien nommé" cropet le début de ton nombre qui peut être un caractère plus loin. - tu donnes des exemples avec des nombres négatifs, ton code ne les gère pas du tout. - j'ai dû en oublier.
Pour trouver les erreurs on doit tester le code petit à petit et non pas écrire un gros bloc illisible et espérer que cela fonctionne du premier coup. Ii est aussi nécessaire d'utiliser un débuggeur. Du devrais repenser et réécrire ta fonction infin_add().
@Dalfab:
Tu as écrit:
> - ne pas mettre de parenthèses lors d'un return.
Tu veux dire return(valeur)? Je ne vois pas le problème, j'en vois partout, même dans du code de "pros".
> - on doit préinitialiser les variables à moins d'avoir une très bonne raison de ne pas le faire.
J'ai la politique opposée. On ne dois jamais préinitialiser les variables à moins que ce soit absolument nécessaire.
C'est souvent une autre façon de camouffler des bugs.
Combien de fois on voit des variables initialisées juste avant un scanf()
De plus les gens initialisent avec n'importe quoi. Il faut que la valeur ait du sens.
C'est comme les gens qui font des tests dans leur code et qui constatent qu'une valeur n'est pas correcte à un certain endroit dans le code.
Plutôt que de chercher l'erreur, ils mettent d'office la valeur supposément appropriée à cet endroit.
Le Tout est souvent plus grand que la somme de ses parties.
- on doit déclarer les variables au plus près de leur utilisation et non pas en début de fonction. - on doit préinitialiser les variables à moins d'avoir une très bonne raison de ne pas le faire.
Le mieux est déclarer les variables à l'endroit où on est capable de leur donner une valeur qui a une signification.
C'est à dire pas
int a;
...
...
...
a = b + c;
mais
...
...
...
int a = b + c;
Préinitialiser une variable avec une valeur arbitraire dont on ne sert jamais parce qu'on la réaffecte ensuite, c'était un truc de temps de la programmation en assembleur (been there, done that) pour faciliter la mise au point, si on on retrouvait la valeur bizarre ailleurs, on voyait d'où ça venait.
---
le commentaire /* calcul de la retenue */ est inutile si
1. la variable est bien nommée (retenue, par exemple, tout le monde comprend ?),
2. dans sa déclaration, on l'initialise en faisant, justement le calcul de la retenue
const int retenue = (somme > 10) ? 1 : 0;
---
Déclarer toutes les variables au début, c'était obligatoire en Fortran II (1954), mais on peut s'en passer en 2020, si on a encore les neurones assez souples pour s'adapter aux bonnes pratiques.
Et mieux, const si c'est possible.
Probablement que dans les langages de nouvelle génération, les déclarations seront const par défaut, et il faudra un mot-clé explicite pour les variables qui peuvent varier. Ca a beaucoup d'avantages (déjà le cas dans rust, je crois) tant pour la sécurité du programmeur, que pour les optimisations qu'un compilateur peut en tirer.
Bon, pour revenir au problème, peut être que des petits dessins pourraient aider.
Si on veut ajouter s1 = "12345" et s2 = "5678901234", on commencera les additions par le dernier caractère. Donc la première chose à faire est de le localiser, dans les deux chaines. Après quoi, on peut les "aligner"
0 i1
| |
s1 = "12345"
s2 = "5678901234"
| |
0 i2
et travailler avec des indices i1, i2 qui indiquent leurs positions, et qui iront vers la gauche.
Après, on remarque qu'il peut y avoir trois phases :
quand on commence, on a des chiffres dans les deux
ensuite, on n'a (peut être) plus qu'une chaine
et enfin, il y a (peut-être) une retenue à ajouter.
- Edité par michelbillaud 17 octobre 2020 à 18:20:01
C'est vrai que ma phrase est un peu trop rapide. Les bibliothèque LibC utilisent fréquemment _write() (ou write()dans cas de POSIX) pour écrire les données non bufferisées. On peut commencer par se poser la question de pourquoi effectuer des écritures non bufférisées d'un unique caractère vers stdout? Celles-ci n'ont d'intérêt qu'avec certains drivers ou pour les transferts de très grande taille.
L'écriture standard C pour avoir cette ignominie serait de désactiver le buffer par setvbuf(stdout,NULL,_IONBF,0) et d'utiliser fputc(ch, stdout) ou putchar(ch) sinon si on veut se cantonner à POSIX ça serait plutôt d'utiliser write(STDOUT_FILENO,&ch,1).
Il est cependant bien garanti que STDOUT_FILENO vaut 1.
my_putchar et cie, c'est juste des exercices faciles à corriger, et qui servent à bourrer le mou aux élèves pour leur faire croire qu'ils "maitrisent la programmation de bas niveau grâce au langage C qui est le plus beau et avec lequel on fait tout dans la meilleure école du monde".
Faut bien qu'ils soient contents.
Horreur : il a oublié de l'appeler dans my_putstr ligne 46, et il va se faire allumer.
- Edité par michelbillaud 17 octobre 2020 à 19:26:39
A propos des parenthèses autour de la valeur de retour d'une instruction return.
Les parenthèses étaient bien nécessaires dans les premières versions de compilateur C de Bell Labs, comme on peut le voir dans le "Programming in CA Tutorial" de Brian W. Kernighan et le "C Reference Manual" écrit par Dennis M. Ritchie (diffusés avec la version d'Unix datant de 1975).
Lorsque le C a été standardisé par l'ANSI en 1989, elles n'étaient plus nécessaires.
Une explication de la persistance des parenthèses est le mimétisme avec du code ancien ou d'anciennes habitudes.
Dans la syntaxe actuelle du C, ce qui est à droite de l'instruction return est évalué puis retourné par la fonction, les parenthèses autour d'un
return (42);
n'ayant pas plus d'effet que de mettre des parenthèses dans une ligne comme
int a = (42);
Le fait de mettre des parenthèses à la suite d'une instruction comme return peut être aussi une indication (ou perçu par un relecteur comme tel) que le programmeur pense à tort que return est une fonction à laquelle on doit passer une valeur entre parenthèses pour son fonctionnement. Ce serait une indication d'une incompréhension du langage : return n'étant, bien sûr, pas une fonction.
Certaines personnes sont plus à l'aise en écrivant un return avec des parenthèses avec des expressions complexes, comme :
return (a + b * c);
C'est plus psychologique qu'autre chose, peut-être cherche-t-on à se rassurer que le compilateur n'oubliera pas l'une des parties de l'expression. De toutes façons ce qui est à l'intérieur des parenthèses sera évalué exactement de la même façon sans ces parenthèses avec les règles de priorité des opérateurs.
Un autre motif serait aussi attirer l'attention du relecteur sur le fait que ce qui est retourné est le résultat du calcul d'une expression complexe et, au final, cela peut être une question de style.
Personnellement, je me guide sur le principe de "moindre surprise". Je mets les trucs quand il y a des raisons de les mettre, parce que quand je relis et que les vois, je me dis qu'il y avait une raison particulière d'y faire attention. Si j'en mets à tort et à travers, ça tire le signal d'alerte pour rien. Dans return, inutile.
Un endroit "inutile" où les mets, c'est dans les conditions d'un opérateur ternaire, parce que ça faire ressortir plus nettement où se trouve la condition. C'est à cause du choix de crottes de mouches : ? pour la notation en C.
int foo = (x + y < z + t) ? a + b : b - c;
ç'aurait été mieux avec avec
int foo = if (x + y < z + t)
then a + b
else b - c;
mais bon, on va pas refaire C.
Réussir une addition infinie
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
En recherche d'emploi.
Le Tout est souvent plus grand que la somme de ses parties.
En recherche d'emploi.