initialisation tableau = segmentation fault ?!?

Bonjour tous,

j'ai un probl�me tr�s bizarre en C++...

j'ai fais un programme "main.cpp" et j'ai seulement initialis� un tableau et �a plante!

voici mon code

Code:

---

1 2 3 4 5 6 7 8 9 10 11

#include <iostream>   using namespace std;   int main() { int tableau[1501][1187]; cout << "test" << endl; return 0; }

---

�a fait longtemps que j'ai pas programm� mais l� �a me parait fort quand m�me...

j'ai essay� sous un autre IDE et il me met "segmenttion fault"

qu'es ce que j'ai fais comme b�tise ?

Ton tableau est selon toute probabilit� bien trop gros pour la pile...d'o� l'�chec de son initialisation.

merci d'avoir r�pondu,

qu'appel tu une pile ?

que faire pour que �a passe ? (car j'ai vraiment besoin de ce tableau...)

pourquoi vouloir un tableau si enorme?

calculons:
int = 4 octets

int tableau[1501][1187] = 1501*1187*4 = 7,126,748 soit 7 go....

EDIT: 7Mo ^^

En fait j'ai un fichier r�sultat (�crit en binaire) qui fait cette taille et que je dois lire...

Citation:

---

Envoy� par Astraya

soit 7 go....

---

plut�t 7 Mo ;)


au passage, si vous savez comment lire un tableau bidimensionnel �crit dans une fichier texte en binaire (32bits) je suis preneur car je gal�re un peu ...

Un fichier resultat ok mais �a n'explique pas pourquoi un si gros tableau. Tu dois pouvoir traiter les informations en plus petites parties successive non?

Citation:

---

plut�t 7 Mo

---

Effectivement ^^
Mais ca ne change pas que c'est trop gros pour la stack. Alloue le dans le heap avec new :)

Code:

---

int * tableau = new int[1501*1187];

---

Citation:

---

Envoy� par Astraya

Mais ca ne change pas que c'est trop gros pour la stack. Alloue le dans le heap avec new :)

---

je ne comprends pas du tout cette phrase (je suis d�butant)
pourrais tu me traduire �a stp en langage plus compr�hensible pour un novice ?

Citation:

---

Envoy� par Astraya

Tu dois pouvoir traiter les informations en plus petites parties successive non?

---

tu as tout � fait raison,
c'est ce que je suis en train de r�fl�chir...

en fait j'ai une matrice sauvegard�e en binaire dans un fichier texte et j'aimerai lire cette matrice, et r�ecrire les resultats dans un fichier non binaire...

saurais tu me dire comment faire ceci stp ?


il faut que je modifie ceci mais je ne sais pas trop comment

Code:

---

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 30 31 32 33

/* fread example: read an entire file */ #include <stdio.h> #include <stdlib.h>   int main () { FILE * pFile; long lSize; char * buffer; size_t result;   pFile = fopen ( "myfile.bin" , "rb" ); if (pFile==NULL) {fputs ("File error",stderr); exit (1);}   // obtain file size: fseek (pFile , 0 , SEEK_END); lSize = ftell (pFile); rewind (pFile);   // allocate memory to contain the whole file: buffer = (char*) malloc (sizeof(char)*lSize); if (buffer == NULL) {fputs ("Memory error",stderr); exit (2);}   // copy the file into the buffer: result = fread (buffer,1,lSize,pFile); if (result != lSize) {fputs ("Reading error",stderr); exit (3);}   /* the whole file is now loaded in the memory buffer. */   // terminate fclose (pFile); free (buffer); return 0; }

---

Citation:

---

Envoy� par Astraya

Tu dois pouvoir traiter les informations en plus petites parties successive non?

---

en fait j'ai fais ceci � la base car si j'ai bien compris la fonction "fread "
elle n�cessite de donner la taille de la chose que l'on veut lire et elle renvoi le r�sultat dans un tableau correspondant....?

Bonne lecture!! :P

Salut,

Citation:

---

Envoy� par membreComplexe12

je ne comprends pas du tout cette phrase (je suis d�butant)
pourrais tu me traduire �a stp en langage plus compr�hensible pour un novice ?

---

Bon, on distingue deux espaces m�moire diff�rents (en fait, il y en a plus, mais deux nous int�ressent ici): la pile et le tas (respectivement stack et heap).

Le premier devrait �tre en r�alit� appel� "pile d'appels". C'est un espace m�moire g�r� par le processeur dans lequel il va empiler, entre autres, les informations relatives � la fonction appelante � chaque fois qu'il y a un appel de fonction (pour pouvoir les r�cup�rer une fois que la fonction appel�e est termin�e) ainsi que les variables pour lesquelles on n'a pas recours � l'allocation dynamique de la m�moire.

A chaque fin de fonction, il va d�cider d'ignorer toutes les informations qu'il a mise sur la pile depuis l'appel de la fonction (c'est vraiment comme une pile d'assiettes : tu ne peux � chaque fois acc�der qu'� la derni�re assiette plac�e sur la pile, mais tu peux d�cider d'en retirer dix d'un coup).

Cet espace m�moire est particuli�rement limit�, de l'ordre de 1 � 2 Mb au maximum.

Si la taille totale des donn�es que tu essayes de mettre sur la pile d'appels, les donn�es vont aller se fourrer � des endroits inattendus qui provoqueront des catastrophes (stack overflow, erreur de segmentation, ...).

Le tas quant � lui repr�sente toute la m�moire accessible par le syst�me : La m�moire r�elle (RAM) + La m�moire virtuelle (swap) et peut donc repr�senter plusieurs Gb de donn�es.

C'est dans le tas qu'iront se loger les donn�es � chaque fois que tu vas faire appel � l'allocation dynamique de la m�moire ( appel de new ou de new[]).

Cet espace m�moire est g�r� non pas par le processeur, mais directement par le syst�me d'exploitation, qui va essayer � chaque fois de trouver un espace m�moire contigu suffisant correspondant � la taille que tu lui as demand�.

Cela implique deux choses:

1. Le syst�me aura beaucoup plus facile � trouver 7Mb d'espace m�moire contigu
2. Si tu ne veilles pas � indiquer au syst�me que l'espace est de nouveau disponible (avec delete), c'est toute la stabilit� du syst�me en lui-m�me qui peut �tre remise en cause.

L'avantage, c'est qu'un pointeur ne fait jamais que quelques bytes (indument traduit sous le nom d'octet en francais) : classiquement, on consid�re (mais ce n'est pas forc�ment vrai) qu'un pointeur est repr�sent� par 4 bytes (32 bits) sur les syst�mes 32 bits et par 8 bytes (64 bits) sur les syst�mes 64 bits.

Comme c'est le pointeur qui prend place dans la pile d'appels, il y a moyen d'en mettre beaucoup plus avant d'atteindre la capacit� maximale de celle-ci :D

Dans le cas pr�sent, therwald et Astraya te disent, en substance, que 7Mb c'est beaucoup trop gros pour tenir dans la seule pile d'appels et qu'il faut donc recourir � l'allocation dynamique de la m�moire pour que les donn�es aillent se nicher dans le tas ;)

Super explication :ccool::ccool::ccool::ccool::ccool::ccool:
merci beaucoup

Sinon, pour r�pondre � ta question initiale, la pile (stack) est l'espace o� sont stock�es toutes les variables locales et les arguments de fonction. C'est typiquement un espace de quelques kilos ou quelques m�gas, et r�server 7Mo sur la pile a peu de chances de marcher.
Si tu veux avoir plus de m�moire, il faut r�server dans l'autre espace de stockage de C++, le tas (heap). A la base, cela se fait par new (avec lib�ration par delete). Pour �viter cette gestion manuelle de m�moire qui favorise les erreurs, il existe des classes standard pour pas mal d'usages. Dans le cas d'un tableau, une des classes est std::vector, qui cr�e un tableau dynamiquement extensible. (note que cette classe fait bien des new/delete, en tous cas par d�faut, mais en interne, de sorte que tu n'as pas � t'en pr�occuper).
exemple:

Code:

---

std::vector<int> vect(1000);

---

r�serve un tableau d'int de taille 1000 (mais si tu ajoutes un 1001 �me �l�ment, l'extension est automatique.)
voir la documentation

EDIT: koala01 d�gaine plus vite que son ombre (ou le mienne en tous cas :aie:)

merci, j'ai bien compris � pr�sent ;)

j'ai trois autres (grandes) questions:

1) "la pile" (stack) existe car elle est plus rapide que "le tas" (heap) ??
Si non, alors pourquoi ne pas tout mettre dans le "le tas" ?

Si ce que je dis est vrai, alors il vaut mieux peut etre manipuler dans un programme les tableaux sous formes de petites donn�es qui seront stock�es dans le stack et de temps en temps vider dans le heap ?
car si on travail toujours dans le heap on peut perdre en terme de performences ?

2) avez vous un cours � me conseiller qui part de z�ro et qui traite ce genre de choses (qui fait le lien entre la programmation et le mat�riel, m�moires...etc?)
un peu comme ce que vous m'avez expliqu� l� mais plus g�n�ral, sur les temps d'acc�s au disque, diverses m�moires...etc


3) concernant mon probl�me de base,
pourriez vous m'expliquez comment modifier ce bout de code
afin de r�cup�rer mes donn�es qui sont sous forme de flottant mais enregistr� en binaire et les convertir en flottant et enregistrer en ascii (en nombres quoi..)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

#include <iostream> #include <fstream> int main() { using std::ifstream; using std::ofstream; using std::ios; ifstream ifs("in.xyz", ios::binary); ofstream ofs("out.xyz", ios::binary);   // char c; while (ifs.get(c)) { ofs.put(c); } return 0; }

---

comme un flottant est cod� sur 4octets il faut que je fasse 4 ifs.get(c) � la suite, puis apr�s que je concat�ne et que je traduise en "float" et qu'ensuite j'enregistre ce float avec "fprintf" ?

je vous remercie pour votre aide !!!

Citation:

---

Envoy� par membreComplexe12

j'ai trois autres (grandes) questions:

1) "la pile" (stack) existe car elle est plus rapide que "le tas" (heap) ??

---

C'est souvent le cas.

Citation:

---

Si non, alors pourquoi ne pas tout mettre dans le "le tas" ?

---

Parce que le processeur ne peut acc�der � l'ensemble de la m�moire qu'au travers de quelques �l�ments constitutifs qui lui sont propres (pointeur d'adresse, accu, pile d'appels, cache "L1","L2","L3", ...)

Citation:

---

Si ce que je dis est vrai, alors il vaut mieux peut etre manipuler dans un programme les tableaux sous formes de petites donn�es qui seront stock�es dans le stack et de temps en temps vider dans le heap ?

---

C'est impossible sans passer par l'assembleur

Citation:

---

car si on travail toujours dans le heap on peut perdre en terme de performences ?

---

Les temps d'acc�s sont, effectivement, plus lents quand on est dans le tas que dans la pile, c'est pour cela que le processeur dispose de diff�rents niveau de cache.

Ce sont des espaces m�moire, g�r�s par le processeur, dont je n'ai pas parl� l� tantot qui permettent de charger les donn�es qui se trouvent dans le tas sous la forme de "lignes" et de "pages", mais qui ne font �galement que maximum 1 � 2 Mb (si je ne me trompe pas), lorsqu'il "charge" la m�moire du tas, que la donn�e � laquelle il devra acc�der apr�s la donn�e dont il a besoin maintenant se trouve dans la m�me ligne / page de cache.

Mais, encore une fois, on se retrouve au niveau de la "magie interne" du processeur et il n'est possible d'en tenir compte (et encore) qu'en assembleur.

Citation:

---

2) avez vous un cours � me conseiller qui part de z�ro et qui traite ce genre de choses (qui fait le lien entre la programmation et le mat�riel, m�moires...etc?)
un peu comme ce que vous m'avez expliqu� l� mais plus g�n�ral, sur les temps d'acc�s au disque, diverses m�moires...etc

---

Je n'en ai pas sous la main, et je ne suis m�me pas sur qu'il existe un cours sp�cifique sur le sujet.

Les informations que l'on peut g�n�ralement retrouver sur le sujet sont soit particuli�rement g�n�rale (par exemple : l'acces disque est plus lent que l'acc�s RAM qui est plus lent que le cache, qui est plus lent que la pile), mais les valeurs en elles-m�mes sont beaucoup trop sensibles � �norm�ment de param�tres mat�riel (taille des bus de donn�es, temps de latences, etc) pour qu'il soit possible d'�tre beaucoup plus pr�cis que cela :aie:

Citation:

---

Envoy� par koala01

C'est impossible sans passer par l'assembleur
Les temps d'acc�s sont, effectivement, plus lents quand on est dans le tas que dans la pile, c'est pour cela que le processeur dispose de diff�rents niveau de cache.

---

si dans le tas c'est plus rapide que dans la pile on peut imaginer manipuler dans un programme que des tableaux statiques (donc allou�s dans le tas)
de taille moyenne pour faire des calculs et lorsque les calculs sont finis et que
l'on veut par exemple stocker les r�sultats (ou faire un certain type de calcul plus important) alors on fait une boucle pour vider tous nos tableau statiques dans un tableau dynamique... ?

si on fait beaucoup de petits calculs et que l'on stock que de temps en temps les donn�s dans la pile alors on peut imaginer y gagner en performence...

par contre, es ce g�nant si on a tendance � surcharge le tas ?
quelles cons�quences �a peut avoir sur l'execution d'un programme ?

Citation:

---

Envoy� par koala01

Les informations que l'on peut g�n�ralement retrouver sur le sujet sont soit particuli�rement g�n�rale (par exemple : l'acces disque est plus lent que l'acc�s RAM qui est plus lent que le cache, qui est plus lent que la pile),

---

en fait c'est �a que je recherche.
j'aimerai bien trouver un cours pour d�butant (mais qui qui se complexifie crescendo) qui permet de faire un point sur le mat�riel qui compose un ordi (processeur, disque dur, Ram, bus....) et qui explique comment un programme utilise ces diff�rents mat�riels
- lorsqu'on fait un variable ou elle est sauvegard�e, pourquoi l� et pas ailleurs... quand on �crit sur le disque pourquoi c'est long...
- j'aimerai bien aussi comprendre c'est quoi un bus, un temps de latence, de la m�moire cache, pourquoi il y en a plusieurs.... pourquoi on a plusieurs petits processeurs plut�t qu'un seul plus gros....etc

as tu une id�e de livre/cours assez g�n�ral sur tout ceci et qui fasse un peu le lien avec la programmation ? (et qui soit pour un d�butant)
ce n'est pas grave si �a ne'explique "qu'en surface" c'est deja pas mal pour moi :)

Citation:

---

Envoy� par membreComplexe12

si dans le tas c'est plus rapide que dans la pile on peut imaginer manipuler dans un programme que des tableaux statiques (donc allou�s dans le tas)
de taille moyenne pour faire des calculs et lorsque les calculs sont finis et que
l'on veut par exemple stocker les r�sultats (ou faire un certain type de calcul plus important) alors on fait une boucle pour vider tous nos tableau statiques dans un tableau dynamique... ?

---

Tu ne m'as pas compris, c'est la pile qui est, a priori, plus rapide que le tas ;)

Citation:

---

si on fait beaucoup de petits calculs et que l'on stock que de temps en temps les donn�s dans la pile alors on peut imaginer y gagner en performence...

---

Oui, Mais cela nous emmene dans le monde de la micro optimisation.

Or,

Citation:

---

Envoy� par Donald Knuth

Premature optimization is the root of all evil

(l'optimisation pr�matur�e est la source de tous les maux)

---

Il est int�ressant, pour sa culture g�n�rale, de savoir ce genre de choses, mais tu gagneras �norm�ment � travailler d'abord sur tes algorithmes en eux m�me pour les rendre le plus efficace possible ;)

Citation:

---

par contre, es ce g�nant si on a tendance � surcharge le tas ?
quelles cons�quences �a peut avoir sur l'execution d'un programme ?

---

Cela peut mener carr�ment au plantage de tout le syst�me : l'application seule dans le meilleur des cas, le syst�me d'exploitation (avec reboot obligatoire) dans le pire des cas :aie:

Citation:

---

en fait c'est �a que je recherche.
j'aimerai bien trouver un cours pour d�butant (mais qui qui se complexifie crescendo) qui permet de faire un point sur le mat�riel qui compose un ordi (processeur, disque dur, Ram, bus....) et qui explique comment un programme utilise ces diff�rents mat�riels
- lorsqu'on fait un variable ou elle est sauvegard�e, pourquoi l� et pas ailleurs... quand on �crit sur le disque pourquoi c'est long...
- j'aimerai bien aussi comprendre c'est quoi un bus, un temps de latence, de la m�moire cache, pourquoi il y en a plusieurs.... pourquoi on a plusieurs petits processeurs plut�t qu'un seul plus gros....etc

as tu une id�e de livre/cours assez g�n�ral sur tout ceci et qui fasse un peu le lien avec la programmation ? (et qui soit pour un d�butant)
ce n'est pas grave si �a ne'explique "qu'en surface" c'est deja pas mal pour moi :)

---

En fait, ce que tu cherches, c'est un cours d'architecture mat�rielle.

Peut etre trouveras tu ton bonheur dans la section qui y est consacr�e du forum :question:

merci beaucoup pour toutes ces informations :ccool::ccool::ccool:

Citation:

---

Envoy� par koala01

Ce sont des espaces m�moire, g�r�s par le processeur, dont je n'ai pas parl� l� tantot qui permettent de charger les donn�es qui se trouvent dans le tas sous la forme de "lignes" et de "pages", mais qui ne font �galement que maximum 1 � 2 Mb (si je ne me trompe pas), lorsqu'il "charge" la m�moire du tas, que la donn�e � laquelle il devra acc�der apr�s la donn�e dont il a besoin maintenant se trouve dans la m�me ligne / page de cache.

Mais, encore une fois, on se retrouve au niveau de la "magie interne" du processeur et il n'est possible d'en tenir compte (et encore) qu'en assembleur.

---

Ce n'est pas tout � fait vrai, il est possible d'en tenir compte, c'est ce qu'on appelle le cache-friendly code.

En revanche, l� ou Koala a quand m�me raison, c'est que c'est d'un niveau un peu trop avanc� pour que tu puisses l'exploiter pour le moment. C'est le genre de micro-optimisations qu'on ne va r�aliser que sur du code qui fonctionne d�j� mais qui a besoin de tr�s hautes-performances.