décomposition en base b d'un entier

[invitee38d9e00]

Bonjour;
J'ai écrire un programme pour "décomposer en base b d'un entier". Mais il marche pas si system("pause"); existe .

#include<stdio.h>
 
int main(void)
{
    int a,b,q,r;
    
    scanf("%d",&a);
    
    scanf("%d",&b);
    
    a=q;
    
    while(q!=0)
    {
    r=q%b;
    printf("le reste est %d\n",r);
    q=q/b;
    }
    
 
    
    return 0;
    system("pause");
}

MERCI DE VOTRE AIDE.
-----

[bzh_nicolas]

Qu'entends-tu par : "il marche pas si system("pause"); existe ." ? Une erreur à la compilation ?

Dans le code que tu as écrit cette instruction en s'exécutera jamais de toute façon.

    return 0;
    system("pause");

L'instruction return va quitter ta fonction main (et donc fermer ton programme), si le compilateur que tu utilises est "strict", il devrait te donner au moins un warning à la compilation.
il faut faire :

    system("pause");
    return 0;

[Jack]

Mais il marche pas si system("pause"); existe

Je ne comprends pas trop non plus ce que ça veut dire.

Le problème de ton programme, c'est que le nombre affiché sera écrit à l'envers.

Puisque tu débutes, prends de bonnes habitudes:
- indente correctement tes programmes (on décale après un while)
- on doit connaitre la destination des variables sans se poser de question => commentaire, ou mieux: donner aux variables des noms parlants (ou lieu de b, préfère base par exemple).

A+

[whoami]

Bonjour,

Je ne comprends pas trop non plus ce que ça veut dire.

Le problème de ton programme, c'est que le nombre affiché sera écrit à l'envers.

Puisque tu débutes, prends de bonnes habitudes:
- indente correctement tes programmes (on décale après un while)
- on doit connaitre la destination des variables sans se poser de question => commentaire, ou mieux: donner aux variables des noms parlants (ou lieu de b, préfère base par exemple).

A+

+1, et :

- l'indentation : chaque bloc intérieur à un autre doit être décalé

- tous les noms (fonctions, variables, constantes ...) doivent être explicites, permettant d'éviter les commentaires

- les commentaires : en tenant compte de la remarque ci-dessus : ils ne sont nécessaires que pour les parties dont la compréhension n'est pas évidente en lisant le code

- éviter les lignes vides trop fréquentes. Elles ne doivent servir qu'à aérer un peu le code (on lit plus facilement plusieurs paragraphes isolés qu'un long chapitre), et/ou à séparer des parties plus ou moins indépendantes dans une fonction (et une meilleure approche est alors de séparer ces parties en fonctions).

- quand on doit entrer une valeur au clavier, il est bon de mettre un petit texte posant la question, précisant ce qu'on attend, y compris les limites autorisées s'il y en a (avec ton code, comment savoir à quoi correspondent les entrées demandées si on n'a pas le code sous les yeux ? Mieux : comment même savoir si le code attend une action de l'opérateur ? [ne rien voir à l'écran ne signifie pas que le programme attend une entrée, il est peut-être en train de calculer {si c'était le cas, ça nécessiterait également un petit message}]).

[A voir en vidéo sur Futura]

[doul11]

Bonjour,

#include<stdio.h>
 
int main(void)
{
    int a,b,q,r;
    
    scanf("%d",&a);
    scanf("%d",&b);
    
    a=q;
    
    while(q!=0)
    {
    r=q%b;
    printf("le reste est %d\n",r);
    q=q/b;
    }

    return 0;
    system("pause");
}

a=q; ? a quoi sert cette ligne ? en plus q n'est pas initialisé.

Puisque tu débutes, prends de bonnes habitudes:
- indente correctement tes programmes (on décale après un while)
- on doit connaitre la destination des variables sans se poser de question => commentaire, ou mieux: donner aux variables des noms parlants (ou lieu de b, préfère base par exemple).

Le "grand luxe" serai de tester la réussite de scanf afin de ne pas traiter des valeurs incohérentes.

[whoami]

Bonjour,

a=q; ? a quoi sert cette ligne ? en plus q n'est pas initialisé.

Oui, je n'avais pas remarqué, ayant plutôt regardé les problèmes de mise en forme, suite au message de Jack.

Le "grand luxe" serai de tester la réussite de scanf afin de ne pas traiter des valeurs incohérentes.

C'est vrai, mais de telles précautions peuvent venir plus tard, c'est pourquoi je n'en ai pas parlé dans mon précédent message.

Mais on peut estimer qu'on doit les prendre en compte dès le départ, ce n'est pas plus mal, et peut-être bénéfique, même si j'en doute un peu.

[doul11]

Mais on peut estimer qu'on doit les prendre en compte dès le départ, ce n'est pas plus mal, et peut-être bénéfique, même si j'en doute un peu.

Il serais peut être intéressant d'en discuter ?

C'est sur qu'au début c'est difficile de prendre des bonnes habitudes, mais une fois habitué ça va tout seul et le temps perdu a écrire du code est gagné sur le temps a déboguer, bien sur on ne peut pas systématiquement tout tester, ça serais trop lourd a coder, ça pourrais même plomber sur le temps d'exécution, c'est là que ce trouve toute la difficulté de l'art : trouver le juste milieu !

[whoami]

Bonjour,

Ce que j'en dit, c'est dans le cadre des nombreux débutants qui passent ici, et qui, pour la plupart, ne s'intéressent absolument pas à la programmation, et n'y touchent que parce que c'est un cours obligatoire.

Les autres comprennent très rapidement la nécessité de faire de contrôles : dès que leurs programmes sont utilisés par d'autres personnes ... bonjour les dégâts.