bus error : quelle signification sous XCode

mator

Membre junior
21 Octobre 2004
91
0
50
Bonjour,
je debute en C et j'aimerai savoir pourquoi j'ai ce message d'erreur : "bus error" (je suis sur XCode).
Je fais build and run puis j'entre la valeur de x et j'ai ce message d'erreur.
Ma 2ème question est celle-ci : Quand on a comme données beaucoup de series (1500 voire 5000) composées de 10 chiffres dans un tableau comme le mien quelle est la meilleure manière de le déclarer?

Merci de votre aide

Voici le début de mon programme :

C
# include <stdlib.h>
# include <stdio.h>
main ()
{
FILE *tom=NULL;
FILE *noke=NULL;
unsigned short cocoder[10];
unsigned short der[10];
unsigned short tab[1500][10] =
{1,6,15,19,21,28,32,34,45,49,2,8,10,13,20,22,33,38,41,46,3,5,12,17,25,26,30,39,4
0,47};

unsigned short xab[1500][10];
unsigned short zab[1500][1],ca[11];
unsigned short i,j,k,a,b,c,d,e,g,h,n,l;
unsigned short m,o,x;
tom = fopen ("cocoder","w");
noke = fopen ("der.txt","r");
scanf("%hu",&x);
for(m=0;m<x;m++) {
for(n=0;n<10;n++) {
fscanf(noke,"%hu",&xab[m][n]);
}
}
 

Céroce

Membre émérite
Ma 2ème question est celle-ci : Quand on a comme données beaucoup de series (1500 voire 5000) composées de 10 chiffres dans un tableau comme le mien quelle est la meilleure manière de le déclarer?
Non, il faut éviter, parce que la mémoire est réservée sur la pile… il me semble que la pile mesure 64 Ko sous OS X, et elle ne sert pas qu'à stocker tes données ! Avec un tableau de short [1500][10], tu prends déjà 2 x 1500 x 10 = 29,3 Ko.

Il faut que tu étudies l'allocation dynamique de la mémoire (fonctions malloc() et free() de stdlib.h). La mémoire est alors allouée sur le Tas (heap), et là, t'es peinard.
Tu dois pouvoir écrire ça:

Bloc de code:
unsigned short* tab = malloc( sizeof(short) * 1500 * 10);

if(tab == NULL)
{
    printf("Impossible d'allouer la mémoire.");
    return;
}

tab[0][0] = 3;
et ne pas oublier de la libérer
Bloc de code:
free(tab);
 

Didier Guillion

Membre d’élite
Club MacG
20 Juillet 2001
3 244
164
58
Toulouse
www.myriad-online.com
Céroce, une petite remarque,

je suis d'accord, c'est mieux d'avoir une allocation dynamique, mais dans ce cas, tu ne peut acceder à celle ci comme un tableau à deux dimensions (le compilateur ne connait pas le nombre de colonnes par ligne).
Le
tab[0][0] = 3;
n'a pas de signification

Il faut passer par une fonction ou une macro pour accéder aux différents élements.

Mator, quelques remarques :

- Evite d'utiliser des valeurs comme 1500 directement dans le code utilise systématiquement des constantes :
#define NB_COLONNES 1500

- Quand tu ouvre un fichier, teste systématiquement que le FILE * n'est pas NULL.

- Et surtout, commente ton code, un source c'est des commentaires avec du code dedant...

Cordialement
 

p4bl0

Membre d’élite
Club MacG
12 Juillet 2004
4 772
425
31
$PWD
p4bl0.net
Céroce, une petite remarque,

je suis d'accord, c'est mieux d'avoir une allocation dynamique, mais dans ce cas, tu ne peut acceder à celle ci comme un tableau à deux dimensions (le compilateur ne connait pas le nombre de colonnes par ligne).
Le
tab[0][0] = 3;
n'a pas de signification

Il faut passer par une fonction ou une macro pour accéder aux différents élements.
Ou alors allouer un tableau à deux dimensions :
Bloc de code:
int **tab = NULL;
tab = malloc(TABXSIZE * sizeof(int *));
assert(tab != NULL);
for (i = 0; i < TABXSIZE; i++) {
  tab[i] = malloc(TABYSIZE * sizeof(int));
  assert(tab[i] != NULL);
}
(faut assert.h pour assert(). Je sais c'est pas très intéressant de testé le malloc parce que ça retourne quasiment jamais voire jamais NULL en fait mais j'ai pris l'habitude et puis bon au cas où...).

Mais ce code n'est pas intéressant si TABXSIZE et TABYSIZE sont prévu à l'avance.

En l'occurence plutôt que 1500 faire l'allocation après avoir demandé la valeur de x serait pas une mauvaise idée.

Mator, quelques remarques :

- Evite d'utiliser des valeurs comme 1500 directement dans le code utilise systématiquement des constantes :
#define NB_COLONNES 1500

- Quand tu ouvre un fichier, teste systématiquement que le FILE * n'est pas NULL.

- Et surtout, commente ton code, un source c'est des commentaires avec du code dedant...

Cordialement
Sur le dernier point j'ai juste un truc à dire.
Je pense tout simplement que c'est faux. Un bon code = un code avec peu de comments.
(dans le sens où y en a pas besoin des comments).

Je m'explique.
Si les noms de mes variables et fonctions (attributs, méthodes et classes, peu importe) sont assez explicite, j'ai pas besoin de comment à deux franc qui disent à quoi correspond quoi.
/* n, b et c sont le nombre de machin, la valeur de bidule et le coût de truc */
int n, b, c;
int nbMachin, biduleValue, trucCost;
C'est un exemple bidon mais perso je préfère cette ligne au deux précédentes

Quelqu'un qui lis du code est censé savoir lire du code donc utiliser des bons noms dans son code évitent déjà beaucoup de comments.
Ensuite ça sert à rien d'expliqué des truc à la con genre /* boucle principale */. Si le lecteur vois pas ça...

IMO les comments sont à utiliser pour expliquer les algo non évident (et dans ceux là je prend aussi les algo qui seront non évident dans 3 ans si le code est relu ! Donc certains truc qui nous paraisse évident aujourd'hui aussi), les regexp compliquées (pareil), ou par exemple en C quand on fork pourquoi pas mettre vite fait un petit /* child */ et /* parent */ au bons endroits pour gagner un peu de temps à la relecture. Les trucs de ce genre quoi.
Et aussi quand ça sert à généré la doc en même temps.

Mais sinon le coup de dire "faut plus de comments que de code" ben tout ce que ça fait c'est des trucs totalement débile où ce qui est dit en comment devrait être clair dans le code sans avoir à lire autre chose.
En plus les comments de ce genre sont rarement maintenu à jour quand y a un petit changement dans la code par exemple.
Et si les comments sont en sms c'est encore pire et ça arrive souvent :-/



Enfin bref voilà je suis pas trop d'accord avec le coup de + il y a de comments + c'est bien.
 

Didier Guillion

Membre d’élite
Club MacG
20 Juillet 2001
3 244
164
58
Toulouse
www.myriad-online.com
Sur le dernier point j'ai juste un truc à dire.
Je pense tout simplement que c'est faux. Un bon code = un code avec peu de comments.
(dans le sens où y en a pas besoin des comments).

Je m'explique.
Si les noms de mes variables et fonctions (attributs, méthodes et classes, peu importe) sont assez explicite, j'ai pas besoin de comment à deux franc qui disent à quoi correspond quoi.
/* n, b et c sont le nombre de machin, la valeur de bidule et le coût de truc */
int n, b, c;
int nbMachin, biduleValue, trucCost;
C'est un exemple bidon mais perso je préfère cette ligne au deux précédentes

Quelqu'un qui lis du code est censé savoir lire du code donc utiliser des bons noms dans son code évitent déjà beaucoup de comments.
Ensuite ça sert à rien d'expliqué des truc à la con genre /* boucle principale */. Si le lecteur vois pas ça...

IMO les comments sont à utiliser pour expliquer les algo non évident (et dans ceux là je prend aussi les algo qui seront non évident dans 3 ans si le code est relu ! Donc certains truc qui nous paraisse évident aujourd'hui aussi), les regexp compliquées (pareil), ou par exemple en C quand on fork pourquoi pas mettre vite fait un petit /* child */ et /* parent */ au bons endroits pour gagner un peu de temps à la relecture. Les trucs de ce genre quoi.
Et aussi quand ça sert à généré la doc en même temps.

Mais sinon le coup de dire "faut plus de comments que de code" ben tout ce que ça fait c'est des trucs totalement débile où ce qui est dit en comment devrait être clair dans le code sans avoir à lire autre chose.
En plus les comments de ce genre sont rarement maintenu à jour quand y a un petit changement dans la code par exemple.
Et si les comments sont en sms c'est encore pire et ça arrive souvent :-/



Enfin bref voilà je suis pas trop d'accord avec le coup de + il y a de comments + c'est bien.
Non, non, je suis d'accord, cela ne sert à rien de commenter pour commenter. Il est évident que le commentaire doit expliquer ce que l'on fait...
J'avais un jour demandé à un elève de commenter son source, et je m'était retrouvé avec des trucs du genre
/* Kesketuboisddoudoudidon*/
/* Sos Un petit fridge */
(véridique)

Déjà au minimum un bon cartouche par fonction, avec une description de ce qu'elle fait, de ce qu'elle recoit, de ce qu'elle ressort.

Et puis, quand on est dans le bain, beaucoup de chose semblent évidentes mais quand on y revient 15 ans plus tard, bizarrement cela l'est moins...

Comme mator débute, je pense que déjà lui demander de commenter ce qu'il fait lui permettra de formaliser un peu mieux ce qu'il veut faire et obtenir également de l'aide plus facilement.

Personnellement je ne cherche pas à aider quelqu'un s'il me fournit un source sans commentaire.

Cordialement
 

p4bl0

Membre d’élite
Club MacG
12 Juillet 2004
4 772
425
31
$PWD
p4bl0.net
Non, non, je suis d'accord, cela ne sert à rien de commenter pour commenter. Il est évident que le commentaire doit expliquer ce que l'on fait...
J'avais un jour demandé à un elève de commenter son source, et je m'était retrouvé avec des trucs du genre
/* Kesketuboisddoudoudidon*/
/* Sos Un petit fridge */
(véridique)
:zen: la classe :style:

Déjà au minimum un bon cartouche par fonction, avec une description de ce qu'elle fait, de ce qu'elle recoit, de ce qu'elle ressort.
Et si possible dans un format "standardisé" qui permet de faire de la génération de doc en même temps.

Et puis, quand on est dans le bain, beaucoup de chose semblent évidentes mais quand on y revient 15 ans plus tard, bizarrement cela l'est moins...

Comme mator débute, je pense que déjà lui demander de commenter ce qu'il fait lui permettra de formaliser un peu mieux ce qu'il veut faire et obtenir également de l'aide plus facilement.
Tout à fait d'accord, mais j'aurais du le dire dans mon post (j'ai oublié au final), je disais ça surtout par rapport à ce genre de truc qui mérite des vrai noms plutôt que des comments.
Bloc de code:
unsigned short xab[1500][10];
unsigned short zab[1500][1],ca[11];
unsigned short i,j,k,a,b,c,d,e,g,h,n,l;
unsigned short m,o,x;
Personnellement je ne cherche pas à aider quelqu'un s'il me fournit un source sans commentaire.

Cordialement
Moi ça dépendrait de si ça à l'air intéressant ou pas et du temps que j'ai devant moi dans ce cas là :p


:)
 

tatouille

Vétéran
1 Juin 2004
5 174
494
Stanford CA
merci a tous d'avoir traduit mon premier commentaire :D
pour l'allocation dynamique c est bien plus elegant avec un calloc et "convinient"

il est facilement envisageable de travailler par offset aka "operation queue"
tout du moins c'est comme cela que j'ai fait sur de grosse matrices
 

tatouille

Vétéran
1 Juin 2004
5 174
494
Stanford CA
Bon p4bl0, on est globalement sur la même longueur d'onde.

Une question, tu utilise quoi pour générer de la doc d'apres les commentaires ?
J'ai developpé mon propre truc et je ne savais pas que cela existait déja...

Cordialement
tu peux mpreinter une synthax javadoc avant "chaque function" mais ca pu
perso je fais ca a la mano ca me permet de ne pas documenter ce qui est opaque
 

grumff

Membre d’élite
Club MacG
9 Novembre 2000
3 606
99
Grenoble, France
www.grumff.com
tu peux mpreinter une synthax javadoc avant "chaque function" mais ca pu
Bah, pour documenter une API, c'est carrément indispensable. C'est aussi utile d'avoir les commentaires de fonctions quand t'as des outils type eclipse (si, même pour le c/c++ avec cdt, c'est pas si mal), qui te réutilisent la javadoc pour te mettre les commentaires dans l'auto-complétion, surtout quand tu dois utiliser le code des autres. Bien sûr, avec des noms de méthodes/variables explicite, parfois ça suffit, je suis pas fan non plus du commentage à outrance "getName() <- retourne le nom", mais de là à dire que ça pue, y'a un gouffre.
 

Céroce

Membre émérite
je suis d'accord, c'est mieux d'avoir une allocation dynamique, mais dans ce cas, tu ne peut acceder à celle ci comme un tableau à deux dimensions (le compilateur ne connait pas le nombre de colonnes par ligne).
Ah, en effet Didier, je n'ai pas essayé le code. Effectivement, le compilateur aurait besoin de connaître au moins la première dimension. Bon, ben Mator, utilise une macro pour calculer l'adresse correspondante à la case dans le tableau.
 

p4bl0

Membre d’élite
Club MacG
12 Juillet 2004
4 772
425
31
$PWD
p4bl0.net
@Didier Guillion:
JavaDoc a été décliné pour d'autre langage.
PhpDocumentor, RDoc (ruby), Doxygen qui est assez similaire semble-t-il...

Mais pour le moment j'ai juste essayé PhpDocumentor une fois, je me suis pas encore mis à ce genre d'outils, c'est juste que je trouve que ça justifie les gros bloque de commentaires, parce que c'est pas con je trouve d'écrire la doc en même temps que le code (sinon ça risque de ne pas être fait, ou de ne plus être autant "dedans" qu'au moment même), et ça permet de ne pas sortir de son éditeur etc...
Puis le coup que la syntaxe soit à peu près standard quel que soit le langage je trouve ça bien aussi :).
 

tatouille

Vétéran
1 Juin 2004
5 174
494
Stanford CA
Bah, pour documenter une API, c'est carrément indispensable. C'est aussi utile d'avoir les commentaires de fonctions quand t'as des outils type eclipse (si, même pour le c/c++ avec cdt, c'est pas si mal), qui te réutilisent la javadoc pour te mettre les commentaires dans l'auto-complétion, surtout quand tu dois utiliser le code des autres. Bien sûr, avec des noms de méthodes/variables explicite, parfois ça suffit, je suis pas fan non plus du commentage à outrance "getName() <- retourne le nom", mais de là à dire que ça pue, y'a un gouffre.

doxygen ca va c'est correcte parce que cela se marie bien avec d'autre lang

Bloc de code:
    /**
     * Constructor used to create this object.  Responsible for setting
     * this object's creation date, as well as incrementing the number instances
     * of this object.
     * @param d A Date object that is used to set the Date/Time this object was created.
     * @see #numberOfInstances
     */
    public JavadocClassExample(Date d) {
      this.objectDate = d;
      this.numberOfInstances++;
    }
voila ca ca pue c'est ridicule ca pollue plus que cela n'aide
 

p4bl0

Membre d’élite
Club MacG
12 Juillet 2004
4 772
425
31
$PWD
p4bl0.net
doxygen ca va c'est correcte parce que cela se marie bien avec d'autre lang

Bloc de code:
    /**
     * Constructor used to create this object.  Responsible for setting
     * this object's creation date, as well as incrementing the number instances
     * of this object.
     * @param d A Date object that is used to set the Date/Time this object was created.
     * @see #numberOfInstances
     */
    public JavadocClassExample(Date d) {
      this.objectDate = d;
      this.numberOfInstances++;
    }
voila ca ca pue c'est ridicule ca pollue plus que cela n'aide
Ben c'est que c'est pensé pour générer de la doc dans un autre format (html, docbook, pdf...) donc ces renseignement sont utiles. Après c'est sûr que pour dans le code ça n'est pas très utile mais c'est pratique quand même de le faire de cette façon je trouve (d'écrire la doc en même temps que le code sans sortir du code).
Donc ouais ça "pollue" en quelque sorte, mais la plupart des éditeurs / IDEs propose le code folding et d'"enrouler" ces comments spéciaux (/**) donc c'est pas si gênant :).