Discussion :

[jamescook]

Bonjour pour mon application j'ai besoin de declarer des gros gros gros tableaux.

voici ma déclaration en structure :

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
 
//STRUCTURE POUR LA MEMORISATION DU TABLEAU ACQUISITION
// Structure d'un élément de mémorisation
typedef struct {
       double date;
       float IBrut;
       float IFiltre;
       float TBrut;
       float TFiltre;
 
}TAB_VAL;
 
//STRUCTURE POUR LA MEMORISATION DES TABLEAUX DES TRAITEMENTS
// Structure d'un élément de mémorisation
typedef struct {
       double milliseconde;
       TAB_VAL acquisition[9000];
       TAB_VAL tab1s[3456000];
}ENREGISTREMENT;

si je compile un simple project qui dans son unité principale a déclaré un ENREGISTREMENT, j'ai le message suivant :

[Lieur Erreur] Fatal: Access violation. Link terminated.
je sais que c'est dût à la lourde allocation de memoire que je demande au compilateur.

Mais je voulais savoir si il y a moyen d'augmenté la limite bcb des tableaux

Ou comment faire pour pouvoir declarer mes enormes tableaux pour qu'il passe?

Si la declaration dynamique est la solution qq pourrais me mettre le bout de code d'une declaration de structure dynamique merci

Merci a tous

[rtg57]

Bonjour,

cette application n'est pas raisonnable.
La structure initiale coute 36 octets.
La seconde structure coute 124 GOctets

Je sais bien qu'aujourd'hui, les machines sont puissantes, mais faut pas exagérer

Tu l'as dit, la solution est dans la déclaration dynamique sur le tas.
Essaie les recherches sur 'new' et 'delete'. N'oublie pas 'delete' pour la bonne gestion des ressources mémoire.
Ensuite il faudra que tu soulages périodiquement la mémoire en sauvant les données au fur et à mesure dans un fichier.

Pourquoi ne pas essayer la gestion par base de données...

[jamescook]

bnjour rtg57,

je comprends pas ton calcul
un double fait 8 octet,
un float fait 4 octet,

donc la premiere structure fait 24 octets

la seconde structure fait :

double milliseconde : 8 octet
TAB_VAL acquisition[9000] : 24*9000 = 216 ko
TAB_VAL tab1s[3456000] : 24*3456000=82 944 ko

Ce qui donne en tout pour la deuxiémee structure : 83,16 Mo
comment tu arrives à 124 Go??????

[Nicolas]

Bonjour,

Pour infos, j'ai copier/coller les structures présentées ci dessus dans un nouveau projet (il n'y a donc presque rien d'autre). Le projet a bien compilé.

A l'exécution, j'affiche la taille d'un objet ENREGISTREMENT : 83160008 octets, donc 81 210 ko ou bien 79 Mo (comme on pouvait effectivement s'attendre d'après le calcul).

J'ai utilisé BDS 2006 (et donc pas de problème de link).

Nicolas

[jamescook]

Bonjour

Merci Nicolas pour ses infos mais cela prouve que c'est une limitation du compilateur BCB 6 puisque chez vous, il n' y a pas de souci de compilation en Borland developer Studio 2006.
En plus vous confirmez la taille mémoire que j'annoncais.
Mais maintenant qq pourrais me dire qu'est ce qui bloque?
Est ce que qq pourrais tester les structures en BCB 6 pour voir si ca marche?

Merci d'avance

[Mat.M]

pour les grosses allocations mémoires il est préférable d'utiliser les fonction systèmes / API Windows comme GlobalAlloc...
car c'est l'OS qui s'occupe des stratégies mémoire
voir MSDN

[yarp]

...ou plutot HeapAlloc. Selon le MSDN il faut mieux utiliser les fonctions Heap* plutot que Global*. Bien qu'on ne voit que des exemples avec Global, y compris chez MS

A propos, ton problème c'est plutot mémoire trop petite.

[Mat.M]

...ou plutot HeapAlloc. A propos, ton problème c'est plutot mémoire trop petite.

Tout à fait ; utiliser l'API la plus appropriée

[asys1]

Bonjour,

j'ai le même problème avec le linker BCB6.
Je fais de l'allocation statique de tableau de milliers de structure d'éléments. Dès que ma constante d'allocation
prédéfinie dépasse un certain seuil il y a problème et cela
malgré que mon exécutable ne dépasse pas le 1 Mo.

J'ai essayé de faire varier la valeur de ma constante prédéfinie
par exemple de 128, 256, 512, ...

Je reconstruis mon projet ensuite plusieurs fois avec la même constante. Au bout d'un certain nombre de fois
de reconstruction j'ai le problème du linker.

Je pense qu'il s'agit d'un problème d'option du linker
ou encore d'alignment de mots mémoire ?

Quelqu'un aurais eu ce problème ou une idée pour le résoudre.

Merci pour votre réponse.

[CGi]

Ton erreur est bizard ?

Si je crée une variable ENREGISTREMENT sur la pile j'ai un Stack Over Flow

Sur le tas ça passe tranquille :

Code :

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

1
2
3
4
 
ENREGISTREMENT *ptab = new ENREGISTREMENT;
  // ton code
 delete ptab;

[DjmSoftware]

bonjour
L'allocation maximum sur la pile est de 16Mb sous BCB 6 ainsi que sous BDS ce qui est trop petit pour accepter cette structure collosale.

Il ne surgit aucun problème lors du linker mais uniquement lors ce qu'une variable de type <ENREGISTREEMENT> tente d'allouer de la mémoire sur la pile.

Il me parait évident que pour traiter de si grands blocs de mémoire il est nécessaire d'utiliser de la mémoire sur le TAS

Par ailleurs le gestionnaire de la mémoire sous BCB et sous BDS attribue la mémoire pour des blocs si grand via un <VirtualAlloc>


Cordialement

[jamescook]

Merci a tous je vais pouvoir m'orienter vers les différents alloc sitées