Bonjour,
 
Sur un système 32 bits, combien de cases mémoires y a t-il  ? 2^32 ?
 
j'ai un doute car il existe le système de segment:offset, du coup n'y a t-il pas plus de cases mémoires disponible ?
 
Par ailleurs, en C++ si on déclare un objet trop grand, du moins sous visual studio, le compilateur sors cette erreur : class to large, je n'arrive pas à comprendre exactement pourquoi...
 
Merci!

Il existe différents systèmes 32-bit. Il faudrait être plus précis.
 
Pour Windows, voir la page http://msdn.microsoft.com/en-us/library/aa366778.aspx qui donne les tailles maximales selon les différentes versions récentes de Windows.
 

Objet déclaré sur la pile ou sur le tas ?
La pile, par défaut, n'a une taille que de 1 mega-octet (autrefois, c'était 64 kilo-octets).

C'est compliqué... mais en gros avec les MMU aujourd'hui sur 32 bits on adresse 64GB sur les ordinateurs et OS grand public.
http://en.wikipedia.org/wiki/Physi [...] _Extension

 
Sur le tas. Mais à priori, sauf erreur de ma part,  c'est dès qu'on dépasse 2^32 que le compilateur génère ce message.
 
donc si je me fie à la réponse de h3bus, le problème ne vient pas d'un nombre de case mémoire insuffisant

 
Toujours de wikipedia

 
Ce qui veux dire en gros que pour dépasser les 4GB, il te faut plusieurs processus...

bon j'avoue c'est complexe..piou y a moulte notions à maitriser pour comprendre le pourquoi du commment concernant cette limitation..vraiment vaste l'info

En général, une case mémoire (l'unité d'allocation de la mémoire vive), c'est 4 ko. Le système y place les pages mémoire nécessaires.
Il y a un maximum pour l'ensemble du système et un maximum par processus (2 Go sur windows 32 bits hors PAE)
 
(mais je ne suis pas sur que ce soit ça la question )

excellent ce lien  
http://members.shaw.ca/bsanders/Wi [...] ileEtc.htm
même si je suis un peu embrouillé par le fait qu'il y est dit que chaque processus a 4GO mais que sur ces 4go 2 sont utilisés par le processus et 2 par l'OS , hors sous visual je pouvais créer des objets de ~4Go...

Montre ta classe voir

ca fait un peu peur, cette histoire "d'objets" de 4Go ...

 
 
Je suis sur un système 64 bits finalement

C'est ça que t'appelles le tas ?

c'est sur la pile erreur mais
 

 
et
 

 
et
 

 
et  
 
 

 
bilan :
 
un tableau peut faire une taille max de 2Go sur la pile ET également sur le tas
un objet peut faire une taille max  de 4Go sur la pile et XXXGo sur le tas
 
 
exact ?
 
si oui pourquoi ? merci

pourquoi tu voudrais faire des tableaux de vecteurs ?
et oui, sinon, ce n'est pas surprenant que tu aies la même erreur en utilisant des int, des char ou des vectors, tant que tu en mets tant que le sizeof de ta classe dépasse une certaine valeur.
 
Mais de toute façon, dans quelles conditions aurais-tu besoin de ca ?

l'erreur n'est pas la meme.
dans le cas du char, 2Go max sont autorisé
dans le cas de l'objet c'est 4GO.
 
Cela provient-il d'une notion de mémorie contigüe ?
 

?

pour les comportements différents, rien à voir avec la contiguité de la mémoire : que ce soit pour un tableau ou pour des membres, tu as le même genre de contraintes sur la disposition mémoire
 
par contre, j'imagine que ce ne sont pas les mêmes limites sur lesquelles tu tombes sur les tailles de classes et tailles de tableau simplement parce qu'une classe, tant qu'elle n'est pas instanciée, ne devrait pas poser de problème technique immédiat si ce n'est la génération de code forcément faux dès que tu veux accéder aux membres (dans un adressage 32 bits, comment tu veux ajouter un offset de 4Go à ton adresse de début d'instance ?)
 
pour ton tableau, s'il est statique, il doit probablement lui réserver la taille dans ton exécutable (suivant les valeurs qu'il aura par défaut) et déjà lui trouver une adresse à laquelle il aura 2Go de mémoire contigüe utilisable (dans ton espace d'adressage évidemment, pas en mémoire physique nécessairement) or, déjà dans ton espaced d'adressage, tu ne peux pas trouver ca : tu as ton code en plein milieu de la plage de 2Go adressable par -et réservée à- ton processus, donc c'est juste pas possible pour lui de s'en sortir.
 
Bref, tout ca pour dire que, de toute façon, tu ne devrais pas avoir à rencontrer de problèmes avec ces limites. Ca montre juste que tu as un problème en amont dans ta conception.

Je voulais juste connaitre l'espace max allouable en statique.
 
"dans un adressage 32 bits, comment tu veux ajouter un offset de 4Go à ton adresse de début d'instance"
 
mais avec la combo segment:offset / pagination peut être que c'est possible non ?
 
on découpe les 4Go en segment donc on a 2^32 segments et on se sert d'un autre registre pour gérer l'offset dans chaque segment
 
EDIT:PRECISON IMPORTANTE sachant que je suis dans un système 64 bits et qu'il y a quand même cette limitation de 4GO

les segments/offset, ca ne se fait plus depuis qu'on est en 32 bits.
 
Au temps du 16 bits, tu avais 16 bits de segment, 16 bits d'offset, maintenant, tu as un 32 bits point barre.
On aurait pu faire un système équivalent pour adresser du 64 bits, effectivement (et ca a peut-être même été fait sur certains OS obscurs, ou des OS plus courants via des tweaks ou des APIs cachées) mais je ne connais pas de telles choses. Pour bénéficier du 64 bits dans ton processus, il faut que ton processus soit 64 bits, c'est la règle, et c'est clairement ce qui sera le moins pénible.
 
Si tu es dans un environnement intégralement 64 bits, assure-toi que tes flags sont bons. Si tu génères bien un exécutable 64 bits, alors c'est probablement une limite compilateur.
 
Edit : d'ailleurs, c'est confus, ta "précision importante". Ce qui est important, ce n'est pas que ton OS soit 64 bits, mais que ton exécutable (et donc ton processus) soit 64 bits.

Et puis c'est plus utile de connaitre l'espace que l'OS est prêt à t'allouer à un moment donné plutôt que des valeurs théoriques.

Y a personne pour faire remarquer qu'il y a probablement méprise sur l'utilisation de std::vector ?

  oui c'est un code que j'ai repris

j'ai cru comprendre que windows en l'occurence alloué 4GO à chaque processus, 2Go pour usage privé 2GO pour je sais pas trop quoi .Cela veut -il dire que lorsque l'on fait new on tappe dans une mémoire déjà pré-réservée?

Ce qu'il faut bien comprendre (ce n'est pas simple à priori mais après tout devient plus facile), c'est que les adresses manipulées dans le processus sont des adresses virtuelles.
C'est une adresse dans l'espace d'adressage du processus et qui n'a pas grand chose à voir avec l'adresse réelle dans la mémoire du PC.
 
Ca permet pas mal de choses :
- l'OS peut déplacer les blocs de mémoire sans se préoccuper du processus, juste en maintenant à jour la table de conversion. Par exemple, pour mettre sur disque la mémoire d'un processus qui ne fait rien et libérer de la place
- conséquence : on peut avoir plus de mémoire utilisée que l'on n'a de mémoire physique
- isolation des processus : un processus ne manipulant pas des adresses réelles, c'est d'autant plus facile d'éviter qu'il n'accède à la mémoire d'un autre processus
- facilite la manipulation des adresses : un processus étant seul dans son espace d'adressage, il n'a pas à tenir compte d'autres processus
- souplesse de l'allocation
 
C'est ce dernier point qui intervient ici. On peut considérer que les adresses < 2 Go sont celles du processus et que celles > 2 Go pointent en fait vers les données/procédures du noyau  
Donc, tous les processus accédant à une adresse > 2 Go accéderont au même endroit. Par contre 2 processus qui accéderaient à une même adresse virtuelle < 2 Go accéderaient en fait à des données stockées en mémoire physique à des endroits différents.
 
Lors d'un accès mémoire, une conversion est faite par le processeur (avec l'aide de l'OS) pour retrouver l'adresse réelle des données à partir de l'adresse virtuelle fournie par le processus.
 
L'espace d'adressage (ensemble des adresses accessibles) est sur 4 Go, mais l'OS ne va évidemment pas les allouer en mémoire dès que tu lances un processus (pour un bloc-note ou un démineur, ce serait gâché). En faisant "new", tu vas demander l'allocation de mémoire physique que l'OS fera correspondre à certaines des adresses virtuelles  

Tout en rajoutant que la pagination permet le partage de pages physiques entre plusieurs process.

 
Quizz:
1) ce code alloue un vector de 100000000 de string;
2) ce code alloue un "tableau" de 100000000 vector de string?

je dirais 2.
Ca peut avoir un sens si on veut une matrice  avec 100000000 de lignes et un nombre variable de colonne, non ?

J'imagine mal ce cas arriver, de toute façon, tu pourras toujours faire des assertions sur ce que contient ta matrice pour avoir une structure plus adaptée (genre matrices creuses ou je ne sais quoi)

imaginons on veut classifier 100M de molécules en précisant pour chacune un nombre variable de caractéristiques et on veut l'avoir en RAM car on effectue toute une batterie de calcul  dessus... on a notre cas

dans ce genre de cas, tu vas travailler avec des Deques, pas des vectors ou des tableaux, parce que précisément, tu n'as pas un strict besoin que tout soit contigu sur l'ensemble de tes données, que ce soit contigu par parties va être suffisant pour te fournir un niveau de performance raisonnable dans ton parcours tout en te retirant tes contraintes ahurissantes sur la mémoire.

je veux bien que tu précises concernant l'aspect contigu.
de ce que je comprends avec vector la mémoire est contigu mais pas avec dequeu ? elle serait comment alors ? un bout sur le disque dur
 
pas sûr de comprendre
merci

 
std::vector<CMolecule>...
 
ton exemple est trop vague/ingénu.

 
que tu utilises un vector, un tableau ou un deque, ta mémoire sera probablement en partie en swap sur le disque dur si tu manipules de trops gros volumes de données. C'est l'adressage virtuel de ta machine qui le permet (ca a été expliqué quelques posts plus haut).
 
La contrainte que tu as quand tu fais un vector ou un tableau, c'est que tous les éléments contenus sont contigus, ca implique que tu as besoin de trouver une plage libre énorme dans ton espace d'adressage virtuel.
 
Si tu passes par un deque, tu estomperas tes contraintes mémoires sur l'adressage virtuel. Tu peux voir un deque comme un ensemble de vecteurs. tes données sont contigües par partie.

je vois merci