Discussion :

[zhao]

Bonjour a tous :-)
voila j'ai borland turbo c++ version 4.5 ,dans mon programme j'ai besoin de creer 2 tableaux :
int t[325000][9],tc[6];

quand je compile mon programme j'ai un message d'erreur :

array size too large ?

donc je comprends que mon tableau est trop grand mais je suis quand meme surpris suis je limiter avec turbo c++ ou alors y a t'il quelque chose a configurer
dans mon edi ? je precise que j'ai 2 GO de mem ,je suis neophyte en programmation donc essayer de faire en sorte que vos reponse me sois comprehensible ;-)
ps) escusez pour les fautes mais je maitrise pas trop votre langue ;-)
cordialement

[Nasky]

Salut et bienvenue sur les forums de Developpez.

Certains compilateurs limitent en effet la taille. Mais je t'avoue que je ne sais pas combien exactement.
En C++, tu as les vecteurs : http://c.developpez.com/faq/cpp/?page=STL#STL_vector
Le fait de passer au 'dynamique' est peut-être une solution à ton problème.
Désolé de ne pouvoir t'aider davantage.

Nas'

[zhao]

meci de ta reponse ,dans mon exemple passez au dynamique cela donnerais quoi avec mes tableaux ? peut tu me faire un petit exemple si tu as le temps car franchement je comprends pas tous avec ses vecteurs ;-)
cordialement

[koala01]

Salut,

Juste une petite chose...

Ton tableau de 32000*9 d'entiers, sur une architecture PC 32 bits classique (je sais, ca peut changer fonction de l'architecture) nécessite de trouver... pres d'un giga de mémoire contigue. (32000*9*4 octets).

Si je suis bien conscient que certains système acceptent de donner autant de mémoire à une seule application... ca peut quand meme faire beaucoup, non

Les premières questions qui me viendraient à l'esprit sont celle-ci:

1- As tu *forcément* besoin de ta matrice complete en permanence ? (ne pourrais tu pas envisager de travailler avec une matrice de 8000*9, par exemple?)

2-Quel type d'acces as tu besoin sur ces données (jamais que l'élément suivant/précédent ou un acces tout à fait aléatoire)

3-Le chargement de la matrice doit il etre effectué d'une seule traite, ou ne récupère tu les informations que "par bloc" (XX éléments à la fois)

4-Faut il prévoir une certaine unicité des données

En effet, rien qu'en restant dans la STL, les réponses que tu fourniras peuvent déjà permettre de te diriger plutot vers d'autres conteneurs que le vector, peut etre plus adaptés à l'usage que tu fera des informations... et je ne parle meme pas encore des autres bibliotheques

Chapeautant le tout, il y aura l'éventuel problème que ton système d'exploitation ou ton compilateur refusera (ou non) de fournir autant de mémoire à ton application... Et que ca t'obligera peut etre à envisager les choses sous un autre angle

[zhao]

Bonjour ;-)

je vais essayer de repondre a tes questions ( je dit bien essayer ;-) )

1- As tu *forcément* besoin de ta matrice complete en permanence ? (ne pourrais tu pas envisager de travailler avec une matrice de 8000*9, par exemple?)

ce tableau est le maximum au fur et a mesure il grandit pour atteindre cette taille max et je suis OBLIGER de le parcourir

2-Quel type d'acces as tu besoin sur ces données (jamais que l'élément suivant/précédent ou un acces tout à fait aléatoire)

toutes les données de mon tableau sont verifier


3-Le chargement de la matrice doit il etre effectué d'une seule traite, ou ne récupère tu les informations que "par bloc" (XX éléments à la fois)


non elle recuperer au fur et a mesure par bloc de 9

4-Faut il prévoir une certaine unicité des données


je comprends pas tres bien cette question mais a priori je dirais NON si ce que je pense de cette question est correct ;-)

cordialement

[koala01]

Excuses moi, je me suis mal exprimé...

J'ai bien compris que ton élément de base, c'est 9 entiers, et que tu as un total de 32000 éléments à gérer.

L'astuce, et il n'y a que toi pour répondre à cette question, c'est de savoir si, une fois que tu es occupé au 152eme élément, il faut que tu puisse retourner au premier ou au 42 eme...

En effet, meme si tu as 250.000 éléments à traiter, mais que, une fois que chaque élément, pris séparément est traité, il "n'y a plus qu'à le sauvegarder quelque part" tu n'a aucune obligation de garder tous les éléments déjà traités en mémoire...

Tu pourrais *presque* décider de traiter chaque élément séparément, puis de l'enregistrer...

Et, dans un cas pareil, un simple tableau de 9 entiers, que tu initialise à chaque fois au début du travail et que tu enregistre une fois le traitement fini est une alternative envisageable (allez, pour économiser un peu de temps en écriture, disons qu'on les enregistrerait par 100 ou par 1000... en disposant alors d'une matrice permettant de les garder en mémoire en attendant leur enregistrement, ca va de soi)

Les 9 entiers me font, c'est une idée farfelue, penser aux neufs comptes génériques d'un plan comptable... La somme mise en débit devant etre, pour une action donnée, équivalente à celle de la somme mise en crédit... Mais peut etre est-ce que je me trompes ?

Dans un cas pareil, chaque enregistrement peut etre considéré comme une structure séparée... Tu géreras les 32.000 éléments, mais sur la longueur , et tu n'as pas *forcément* besoin de garder tous les éléments déjà gérés en mémoire

Par contre, de fait, si lors du traitement du Nieme élément, il faut que tu puisse retrouver n'importe quel élément déjà traité (ou non, d'ailleurs), là, effectivement, la solution donnée dans les paragraphes précédents n'est plus envisageable...

Quand tu me dis que toutes les données du tableau sont vérifiées, je me doutais que tu n'allais pas non plus en passer certaines pour le plaisir

Comprend bien que ton pire ennemi dans le cas présent, c'est la mémoire dont tu disposes (et que le système veut bien te donner)

Imagines quand meme que, avec un rouleau de papier toilette de 9 cm de large, en écrivant les nombres sur un centimetre carré à chaque fois, il te faudrait 3,2 km de papier pour écrire les 32.000 élément de 9 nombres...

Je reposes donc ma question: es tu sur d'avoir besoin en permanence des 32.000 éléments en mémoire (ou de tendre vers ce point)?

[zhao]

ok je vais expliquer cela plus clairement car je me suis mal exprimer d'autant plus que j'ai pas expliqué ce que fait ce programme .

c'est un probleme de " combinatoire" et non de compta ;-)

voici mes tableaux :
int t[325000][9],tc[9]; ( 9 et pas 6 erreur de frappe)

je genere toutes les combinaisons par exemple de 9 parmi 25

la combinaisons generer en cours est stocké dans tc[x]

cette combinaisons est la base pour mon analyse combinatoire donc celle la je la garde et la stoke dans t[0][y] cette combinaison est la suivante :

1 2 3 4 5 6 7 8 9

je genere la deuxieme combinaisons que je stock dans tc[x] elle contient ceci

1 2 3 4 5 6 7 8 10

je la compare avec la combinaison garder dans T[y][v] SI il y a moins de 8 chiffres en commun je la conserve et la stock dans T[y+1][v] et j'aurais donc 2 combinaisons maintenant dans mon tableau T sinon je genere la combi suivante 1 2 3 4 5 6 7 8 11 etc... supposons que j'ai maintenant 10 combinaisons stocker dans T la combinaison generer devras etre comparer a ses 10 combinaisons au MAXIMUM je dit MAXIMUM car aussitot que la combinaisons generer ne rempli pas la comdition cité plus avec une seule combinaisons inutile de tester les autres je passe a la suivante etc....
c'est ce que je nomme probabilité -1 .
berf ce tableau T comme tu l'auras deviner va grossir de + en + et les traitements vont etre de plus en plus long vu que ce tableau grossit donc les tests serons plus nombreux .
donc mon but c'est d'essayer de l'optimiser un max ;-)
suis je bien clair ?

[Luc Hermitte]

C'est un problème de pile. Chaque compilo a ses propres paramètres pour cela.
C'est un peu la 3e fois en 2 semaines qu'elle est posée cette question.

Et je crains que turbo C++ 4.5 soit beaucoup trop vieux pour supporter les vecteurs.

[zhao]

merci pour toutes vos reponses .
effectivement turbo c++ est limité , donc je suis passé a dev cpp qui lui n'est pas limité je viens de le telecharger et aucun probleme de taille avec mes tableaux ,bon il va falloir que je me familiarise avec cet IDE qui m'as foi me semble pas mal du tout ;-)
merci a tous .
cordialement