Discussion :

[sneb5757]

bonsoir je voudrais faire une fonction qui initialise un tableau a deux dimensions a 0.Le corps de la fonction est juste(dur de se tromper)mais quand j essaie de faire une fonction et la reutiliser dans un main() j ai un probleme.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
#include <stdio.h>
#include <stdlib.h>
#define NB_ELEM 10
 
 
int init_tab(int tab[ NB_ELEM ][ NB_ELEM ])
{
 
     int i,j;
     for(i=0;i<2;i++)
     {
                     for (j=0;i<2;j++)
                     {
                      tab[i][j]=0;
                      }
     }
 
}
 
main()
{
    int tab[ NB_ELEM ][ NB_ELEM ];
    tab=init_tab( tab[NB_ELEM][ NB_ELEM ]); 
 
 
 
 
}

voici la reponse du compilateur:

C:\Documents and Settings\Administrateur\Mes documents\tab.cpp In function `int main()':

23 C:\Documents and Settings\Administrateur\Mes documents\tab.cpp invalid conversion from `int' to `int (*)[10]'

23 C:\Documents and Settings\Administrateur\Mes documents\tab.cpp initializing argument 1 of `int init_tab(int (*)[10])'

23 C:\Documents and Settings\Administrateur\Mes documents\tab.cpp incompatible types in assignment of `int' to `int[10][10]'

est ce que vous pouvez m aidez ça sdoit etre simple ?

[gl]

bonsoir je voudrais faire une fonction qui initialise un tableau a deux dimensions a 0.Le corps de la fonction est juste(dur de se tromper)mais quand j essaie de faire une fonction et la reutiliser dans un main() j ai un probleme.

Il faut fournir a init_tab le tableau, pas un element du tableau. L'appel dans le main est donc :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

tab=init_tab(tab);

[InOCamlWeTrust]

Ta fonction init_tab ne retourne pas de int, non plus... donc fais attention, car le valeur de retour est n'importe quoi dans ce cas !

[asmanur]

Dans le second for c'est 'j<2' et pas i, sinon tu obtiens une boucle infinie.

Et pourquoi 2 et pas MAX_ELEM ?

[sneb5757]

parce que j ai fait des modif et j ai oublié de corriger les element mais j avais vu j ai corrigé.je donne quel type de sorti alors ?

[sneb5757]

c est bon j ai mis un void et j ai corrigé mes fautes.

Me sens tres con la

[InOCamlWeTrust]

Je ne saurais te conseiller que très vivement de placer un "return;" dans ta fonction retournant void, de façon à rendre clair et visible l'endroit où la fonction s'arrête ; ça t'évitera de nombreux problèmes par la suite.

[Emmanuel Delahaye]

Je ne saurais te conseiller que très vivement de placer un "return;" dans ta fonction retournant void, de façon à rendre clair et visible l'endroit où la fonction s'arrête ; ça t'évitera de nombreux problèmes par la suite.

Euh, pourquoi ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
void init_tab (int tab[][NB_ELEM])
{
   size_t i;
   for (i = 0; i < NB_ELEM; i++)
   {
      size_t j;
      for (j = 0; i < NB_ELEM; j++)
      {
         tab[i][j] = 0;
      }
   }
}

Elle s'arrête à la fin tout à fait normalement, pourquoi faire un return ?

[InOCamlWeTrust]

Je préfère toujours utiliser un return pour deux raisons :

1- lisibilité : on voit tout de suite où le programme termine
2- éviter les bugs de codage : si le programme a besoin de s'arrêter avant la fin dans une des deux branches de if(){...}else{...} mais pas dans l'autre, c'est une bonne habitude d'utiliser le return... de plus, si on utilise des goto (qui sont parfois très pratiques), il est nécessaire d'adopter une bonne hygiène.

Ici, je suis d'accord : tout va bien dans le code qu'il a écrit.

[Emmanuel Delahaye]

Je préfère toujours utiliser un return pour deux raisons :

1- lisibilité : on voit tout de suite où le programme termine

Une seule sortie par fonction. C'est ça "La Regle de Lisibilité".

2- éviter les bugs de codage : si le programme a besoin de s'arrêter avant la fin dans une des deux branches de if(){...}else{...} mais pas dans l'autre, c'est une bonne habitude d'utiliser le return... de plus, si on utilise des goto (qui sont parfois très pratiques), il est nécessaire d'adopter une bonne hygiène.

PIPO. Voir la règle précédente.

[InOCamlWeTrust]

Pourquoi une seule sortie par fonction ?

Si tu t'efforces de respecter ta règle, tu te retrouveras à devoir faire des choses qui sont source de bug ultérieurement.

Par exemple, comment transformer ce schéma-ci ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
if(/* ... */)
{
    /* ... */
 
    if(/* ... */)
    {
        /* ... */
 
        return X;
    }
    else
    {
        /* ... */
    }
}
else
{
    return Y;
}
 
/* ... */
 
return Z;

[Trap D]

Dans ce cas, moi je définis une variable retour initialisée avec une valeur par défaut.

[InOCamlWeTrust]

Et si X et Y peuvent prendre n'importe quelle valeur, y compris la valeur par défaut, tu fais quoi ?

[Trap D]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
retour = Z;
 
if(/* ... */)
{
    /* ... */
 
    if(/* ... */)
    {
        /* ... */
 
        retour = X;
    }
    else
    {
        /* ... */
    }
}
else
{
    retour = Y;
}
 
/* ... */
 
return retour;

Je ne vois pas trop ce que tu veux dire.
Celà dépend evidemment de ce qui est fait dans le dernier /*.....*/, mais on peut supposer que tu ne modifies pas de variables globales ou de tableaux ou autres passés en paramètres...

[Emmanuel Delahaye]

Pourquoi une seule sortie par fonction ?

Parce que c'est plus simple à coder, à débugger, à maintenir, à lire et que le code écrit est plus cohérent.

Et puis c'est une des règles canoniques de la Programmation Structurée, qui est ma Religion. Et la religion, c'est sérieux ! Après avoir connu les errances du BASIC, la découverte du Pascal m'a enfin révélé La Vérité.

Si tu t'efforces de respecter ta règle, tu te retrouveras à devoir faire des choses qui sont source de bug ultérieurement.

Ben non, justement, et c'est ça qui est bien. (Libération de ressources cohérente, notamment, moins de répétition de code...)

Par exemple, comment transformer ce schéma-ci ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
{
   /* valeur par defaut */
   int ret = Z;
   if ( /* ... */ )
   {
      /* ... */
 
      if ( /* ... */ )
      {
         /* ... */
 
         ret = X;
      }
      else
      {
         /* ... */
      }
   }
   else
   {
      ret = Y;
   }
 
   /* ... */
 
   return ret;
}

[InOCamlWeTrust]

Je me suis mal exprimé : si ni X, ni Y et ni Z sont des constantes, ton schéma ne marche plus ! En clair, si le calcul de Z se poursuit en fin d'algorithme, il faudrait faire comment ?

[Thierry Chappuis]

Je me suis mal exprimé : si ni X, ni Y et ni Z sont des constantes, ton schéma ne marche plus ! En clair, si le calcul de Z se poursuit en fin d'algorithme, il faudrait faire comment ?

Là, j'ai du mal à voir où tu veux en venir? Le schéma proposé par Emmanuel me semble correct, d'ailleurs le style de code que j'utilise dans ce genre de situation, et c'est bien plus lisible de n'autoriser qu'un seul point de sortie à la fonction.

Mujigkalement

Thierry

[Trap D]

Je me suis mal exprimé : si ni X, ni Y et ni Z sont des constantes, ton schéma ne marche plus ! En clair, si le calcul de Z se poursuit en fin d'algorithme, il faudrait faire comment ?

Tu pourrais donner un exemple C de ce que tu envisages ?