Je dispose d'un programme dans lequel je manipule des tableaux de double dont la taille est variable. Pour le moment je déclare en mémoire environ 20 tableaux monodimensionnels contenant chacun 720 doubles. Je n'ai pas de problème de compilation. Je décide ensuite d'augmenter la taille de ces tableaux à 72000 double par tableau. Je compile et j'ai un message d'erreur (lancé par windoze xp) incompréhensible à base 000xxx. J'ai  un P4 avec 1Go de ram. Je pense que ça peut encaisser 20 tableaux de 72000 doubles...on bien peut-être que non...? Pouvez-vous m'éclairer?
 

message d'erreur à la compile ou à l'exécution?

La pile, le tas, les tailles pas défaut des compilos, toussa quoi.  
 
Mais revenons sur l'erreur. Windows affiche une boite de dialogue avec juste marqué "000xxx" ? T'as un Windows piraté ou quoi ?

8*72000*20 => 11520000 octets,soit 11250 ko jpense qui a encore de la marge

Il ne t'as pas dit où il alloue ses tableaux. Si c'est en variables locales, alors 11Mo, ça fait beaucoup pour une pile, non ?

le C ANSI garantie une taille maximale d'un objet de 32K et le C99 de 64K si je me souviens bien. Même si ton système peut aller beaucoup plus loin, il me semble dangereux d'avoir des objets de telle taille dans la pile

je suppose que c alloue a coup de malloc() ou de new, parce que mettre ca sur la pile ou en global c pas tres recommandé

En lisant les messages de GROFRED, j'ai la mauvaise impression qu'il fait du C comme on écrit du Fortran 77, auquel cas je crains qu'il ne fasse complètement fausse route.
En F77, il n'y a pas de notion d'alloc dynamique, que je sache et on ne fait pas de distinction entre pile et tas.

et oui je pense que "el muchacho à raison"...malheureusement il y a des trucs que je ne comprends pas en c. Je me suis manifestement fait une représentation du fonctionnement qui n'est pas la bonne. Pour moi quand je déclare mes tableaux j'ai des trucs du style:
 

 
Ce qui me parait flou c'est cette histoire de pile et de tas...moi je pensais que la déclaration permettait d'allouer en mémoire l'espace nécessaire et que le compilo se charge de stocker les variables en registre ou en ram suivant les besoins...
Je posterais plus tard le message réel envoyé par windows...
 
J'utilise DEVC++ et mon compilateur est gcc.

#define N 72000
 
double tab1[N];
.....
double tabi[N];
.....
double tab20[N];  
 
 
 
va te pendre ...

Tu as declaré tes tableaux en tant que variables globales. Est-ce que tu en as réellement besoin ?
Et tu peux utiliser des tableaux à plusieurs dimensions !
Pour ne pas avoir de problème de taille des tableaux et pour que ce soit un peu plus "propre", tu peux faire une allocation dynamique :

Voilà, ça devrait être un peu mieux. n'oublie pas de désallouer à la fin du traitement ou même en plein milieu si tu dois brusquement le stopper.

 
Pas besoin d'être insultant. Pour quelqu'un qui n'a fait que du Fortran jusqu'à présent, ça n'a rien d'étonnant, vu qu'en Fortran (77), les tableaux statiques sont la seule "structure" de données qui existe (ce pourquoi j'ai détesté le Fortran dès le premier jour que j'ai dû en faire à la fac). Bref, GROFRED a bcp à apprendre avant de pouvoir écrire du C.
 
GROFRED > je ne peux que te conseiller d'arrêter complètement d'écrire du code et d'étudier le Kernighan & Ritchie sérieusement pour maitriser les notions de pointeur, allocation/désallocation, et structures de données. C'est un minimum, car Sans maitriser cela, tu n'iras vraiment pas loin en C. Le C, ce n'est pas simplement un changement de syntaxe / Fortran, c'est bcp, bcp de concepts et de connaissances que l'on n'a pas besoin d'avoir en Fortran.
 
D'ailleurs, vu que tu débutes, personnellement, je te conseillerais d'apprendre directement le C++.  
Tu écriras certainement du code "dégueu" , mais tu feras probablement bcp moins d'erreurs parce que le compilo t'aide plus, tu manipules bcp moins de pointeurs directement (grâce à la notion de références), et ça sera tjrs moins "dégueu" qu'en C.

darkoli > ton code est pas meilleur. voyons voir si tu saurais alloué N double[N]

GROFRED > bonjour, tu fais du C, si tu prends un livre de C, tu ne trouveras la notion de variable globale que dans les derniers chapitres. Je gueuler surtout pour le tab1 tab2 tab3 ... et pour le fait de faire 20 tableaux de 1Mo ...

ok

non pas OK. parce que si tu traites une grande quantité de données, genre une énorme NxN, c'est bien mieux quand c'est contigu
 
 
mais dis moi, ton N, c'est ta limite max <Assez Gros Pour Que Ça March> ?
 
 
darkoli > j'attend toujours

 
Taz, pour te donner une idée de ce à quoi du code Fortran peut ressembler, en Fortran (je parle du 77), il n'y a :
 - pas de structures de données si ce n'est des tableaux statiques (déclarés comme il l'a fait). Oui, en Fortran, la limite c'est bien "assez gros pour que ça marche"
 - aucune notion de portée. TOUT est global (enfin presque).
 - une notion de typage minimaliste puisque limitée aux types fondamentaux (int, float, char).
 
Et c'est pratiquement tout, le reste n'étant guère plus qu'une infâme bouillie de GOTO dans tous les sens. Donc quand tu penses aux millions de lignes de code Fortran écrit par des gorets qui n'utilisent même pas à plein les quelques facilités du langage, tu pleures.

OK, alors c'est pas la peine de répéter la même chose en C, toute façon, il ira pas bien loin comme ça

Bien tout d'abord, j'ai suivi la remarque de "el muchacho" j'ai acheté le delannoy "langage C". J'ai pas trouvé le K&R mais je vais essayer de le trouver comme c'est la bible...
 
Concernant mon programme il s'agit d'un programme de simulation de la combustion dans un moteur 4 temps sur 720 degrés. Pour faire le calcul, j'utilise la méthode d'intégration d'euler qui n'est précise que si on utilise un pas d'intégration fin soit 1/100 de degrés total je me traîne avec 72001 doubles juste pour le tableau contenant les angles vilebrequin. De là avec des relations diverses et variées, je calcule la pression, le volume de la chambre de combustion, la température, la masse, la vitesse du piston etc etc. Au total j'ai environ 20 variables du système qui ont une valeur (un double) associées à chaque angle. Comme je dois récupérer toutes ces valeurs dans un fichier externe je souhaitais les stocker dans des tableaux différents pour plus de clarté. En conséquence je suis amené à manipuler 20 tab de 72001 valeurs de doubles...charmant. En variables globales puisque je souhaite les écrire toutes dans un fichier, j'ai besoin qu'elles restent stockées quelquepart...j'espère avoir été suffisamment exhaustif dans la description de mon problème et de pouvoir justifier pourquoi j'ai voulu faire comme ça...même si apparamment c'est "pure folie" ;-)

Je dois faire quoi ?
Mon code "fonctionne", même si je n'aurais personnellement pas utilisé cette méthode.
Que veux-tu dire par "si tu saurais alloué N double[N]", un tableau à deux dimensions de taille NxN ?

double (*tab)[72000];  
 
...
 
tab = malloc( n * sizeof *tab );

Pour éclairer votre lanterne sur mon profil programmation, j'ai eu un enseignement en école d'ingé sur le C fait par des non spécialistes et quand j'étais en thèse j'utilisais Matlab: un environnement de calcul scientifique avec interpréteur de commande. Le langage est hyper permissif dans le sens où tu déclares tes variables sans te soucier du type, pour les tableaux l'allocation mémoire est automatique. La syntaxe est proche du C. Pour finir cette usine à gaz utilise des librairies de calcul LAPACK en FORTRAN. Je m'aperçoit maintenant que toutes ces "simplifications" n'aident pas à acquérir de bonnes habitudes de programmation...

ouala !

Pour des langages spécialisés comme Matlab, le typage dynamique est commode et les erreurs n'ont pas de grosses conséquences, les pb étant plutôt de l'ordre du calcul numérique. Mais pour ce qui est du Fortran par exemple, qui est effectivement une simplification (à l'époque des premiers Fortran, il n'y avait rien d'autre), à partir du moment où un langage comme le C a été créé, ta conclusion est effectivement exacte. Et la facilité d'apprentissage du Fortran n'est pas un avantage par rapport aux millions d'heures perdues à déboguer du code Fortran.

Bien à propos de cette histoire de tableau, il semble que ce code fasse planter le système sous win98 et envoie un message d'erreur sous win xp
 

 
Il me semble clair que le système est incapable de prendre en charge cette quantité d'information et d'allouer la mémoire suffisante. Cependant, Matlab accepte des tableaux [10000]*[10000] et dans ce cas bouffe 800 mo de ram. Pourquoi n'en est t'il pas de même avec mon prog en C? théoriquement à l'image de Matlab je devrais pouvoir déclarer un tableau de 10000*10000...
 
J'ai essayé d'augmenter le fichier de mémoire virtuelle (j'ai 1go de ram et un fichier de 2go de mem virtuelle). Je compile sous gcc mais avec VC++ ça me renvoie le même message d'erreur.
 

mais on t'a dis de ne pas déclaré ca sur la pile un objet aussi gros ??

depuis le début du thread, cris et taz essaient de t'expliquer que le C n'est pas capable de gérer des objets d'une taille pareille "tout seul".
 
Il faut que tu réserves toi même la mémoire (cris t'as montré une manière de le faire) et alors seulement tu peux taper dedans
et il ne faut pas oublier de libérer la mémoire allouée quand tu n'en as plus besoin.

toute façon, quand tu demandes 800Mo de RAM, tu les as pas, le système fait le flemmard et te les fileras à la demande  
 

Super, maintenant, il se passe quoi si tu remplis ton tableau ? Windows va se vautrer comme une merde

 
non non il accepte le tableau rempli...Concernant les allocations mémoire je pensais qu'écrire:
 
double TABMAX[72000];
 
ça permettait d'allouer la mémoire nécessaire une fois pour toute (dans l'hypothèse ou ç'est possible) et que malloc permet d'allouer dynamiquement de la mémoire c'est à dire pour moi agrandir la taille du tableau pendant l'exécution du prog. Dois-je comprendre que malloc "force" une allocation mémoire qui ne serait pas possible en faisant:
 
double TABMAX[72000];
 
?

menteur

Pas de problèmes pour Windows.  
Windows NT 4.0 monte à 2Go, et Win2K et XP montent à 3 Go pour le userland (1Go est reservé pour le systemland). Sur une archi 32 bits bien sûr.
 

nan, mais c'est bon, si t'as un soft qui bouffe 800Mo de mémoire, ton système, il est a genou, encore plus si c'est windows

Nan nan. Il y a eu du progrès ces 5 dernières années.  
 
Windows va être clairement à genou si tu n'as que 512 Mo de RAM (plus à cause de ses E/S bloquantes que à cause d'une gestion de la RAM foireuse).  
 
Mais vu qu'il en a 1Go, une appli bien codée (et je pense que des trucs comme Matlab, Photoshop et autres sont très bien codées), ça passe comme une lettre à la poste.

bah j'avais pas vu qu'il avait 1Gigo

nan nan ça passe trankil avec 1go et windaube s'en tire bien. Je suis pas pro micromou mais bon un 2000 ou un XP mériterait presque le nom d'OS. Le problème c'est que micromou à mis dans la tete des gens qu'aussi vrai que le soleil se lèvera demain, l'informatique "ça plante" et c'est normal...je pense que les codeurs microsoftiens qui ont pondu win98 ont le même niveau que moi en C...
 
:-)

Ben oui, garçon, t'es fort mais trop impulsif et plein de préjugés, c'est ton problème et ça te jouera des tours. Etre à l'écoute, c'est important.

GROFRED > ca alloue pas au meme endroit, la pile à une taille tres limité et independante de ta quantité de memoire virtuelle

 
C'est du C++ ca, pas du C... si tu programmes en mélangeant C et C++, pas étonnant que ca plante...