bus error : quelle signification sous XCode

[mator]

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]);
}
}

 

[tatouille]

bus error en C ET NON XCODE === MEMORY PROBLEM
comme tous les crashes logiciels

c'est quoi cette merde fscanf(noke, "%hu", &xab[m][n]);

noke est vide donc ca merde...

pour ton tableau tu pourrais faire ca dynamiquement

mais pour quoi unsigned short tab[1500][10]
t'es malade?

http://www.cprogramming.com/tutorial.html#ctutorial

 

[Céroce]

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:

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

free(tab);

 

[Didier Guillion]

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]

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 :

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]

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]

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)

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.

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à

 

[Didier Guillion]

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

 

[tatouille]

merci a tous d'avoir traduit mon premier commentaire
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]

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]

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

J'avais utilisé doxygen, sinon la javadoc doit effectivement pouvoir être utilisée sur d'autres langages que le java.

 

[grumff]

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]

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]

@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 .

 

[Didier Guillion]

@p4bl0

Intéressant, je vais y jeter un oeil. Merci.

Cordialement

 

[tatouille]

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

    /**
     * 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]

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

    /**
     * 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 .