Discussion :

[deubelte]

Bonjour

J'essaye de mettre en pratique une méthode donnée dans le livre :"Effective C++" de scott meyers. Il s'agit de gérer les exceptions de mémoire ( plus précisément l'item 7 dans la version que je lis). Il est écrit:


To specify the out-of-memory-handling function, clients call set_new_handler, which is specified in the header <new> more or less like this:

Code :

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

1
2
typedef void (*new_handler)();
new_handler set_new_handler(new_handler p) throw();

You use set_new_handler like this:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
void noMoreMemory()
{// function to call if operator new can't allocate enough memory
cerr << "Unable to satisfy request for memory\n";
abort();
}
int main()
{
set_new_handler(noMoreMemory);
int *pBigDataArray = new int[100000000];
...
}

C'est ce que j'ai fait, mais je n'arrive pas a faire planter le programme pour qu'il fasse appel à la fonction noMoreMemory.
Le compilateur accepte parfaitement ce qui est écrit. Pourriez vous me donner un exemple de code qui fasse appel à la fonction noMoreMemory.

merci

[koala01]

Salut,

De manière générale, si ca ne pante pas, c'est simplement parce que tu dispose d'assez de mémoire pour allouer un tableau de cent millions d'entiers

Si tu travailles en mode 32 bits, il n'est pas exclu que la mémoire ne soit limitées qu'à concurrence de... 2Gb par application, alors qu'ici, tu te limite royalement à... environ 800Mb (et encore).

Ce que tu peux donc faire, c'est soit travailler par tests successifs afin de déterminer au delà de quelle quantité tu commencera à ne plus avoir assez de mémoire, soit profiter du fait que les différentes collections de la STL manipulent en interne l'allocation de la mémoire pour les différents éléments.

Un code proche de

Code :

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

1
2
3
4
5
6
7
8
9
int main()
{
    set_new_handler(noMoreMemory);
    std::vector<int> tab; // un tableau d'entiers
    while(1) // condition toujours vraie
        tab.push_back(1); // lancera une exception bad_alloc lorsqu'il n'y aura
                          // plus assez de mémoire pour rajouter un élément
    return 0;
}

[deubelte]

Si tu travailles en mode 32 bits,

>>je travaille en mode 32bit effectivement (win32).

il n'est pas exclu que la mémoire ne soit limitées qu'à concurrence de... 2Gb par application,

Comment connais-tu la quantité maximale de mémoire allouée par application? et la mémoire totale disponible?

Par exemple si tu crées une application qui, simplement alloue un tableau de 100000000 entiers, comment savoir, une fois lancée avec un .exe la quantité de mémoire qu'elle va occuper?

Autre exemple, si tu lances deux applications Excel, la mémoire occupée sera deux fois supérieure à la mémoire occupée si tu lances une applications excel.

Quand on développe un projet, comment connais-t-on la mémoire maximale que l'on peut allouer?

Ce que tu peux donc faire,

En fait, j'ai mis deux fois

Code :

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

1
2
int *pBigDataArray = new int[100000000];
int *pBigDataArray = new int[100000000];

et cela plante effectivement.

[koala01]

Comment connais-tu la quantité maximale de mémoire allouée par application?

La quantité maximale de mémoire qui peut être allouée pour une application est fonction:

• du système d'exploitation pour lequel l'application est prévue
• de la taille des pointeurs (du nombre de bits utilisé pour permettre de représenter une adresse mémoire)
• La quantité de mémoire totale disponible

La limite effective étant la première des deux qui sera atteinte.

Windows 32bits limite la quantité de mémoire disponible par application à... environ 2Gb, et la plage d'adresses atteignable avec un pointeur codé en 32 bit est de 4Gb (4 294 967 296 adresse potentielles pour être précis).

Comme l'allocation de mémoire va devoir passer par une demande auprès du système d'exploitation pour disposer de la mémoire suffisante, si l'OS refuse de donner plus de mémoire à l'application, l'allocation échouera

(bon, je prend des raccourcis et je reste simple dans l'explication, mais le principe est là )

et la mémoire totale disponible?

La quantité de mémoire totale disponible est simplement la somme de la quantité de mémoire "physique" (la RAM) dont l'ordinateur dispose et de la mémoire virtuelle (SWAP / "fichier d'échange" sous windows) définie pour le système d'exploitation.

Par exemple si tu crées une application qui, simplement alloue un tableau de 100000000 entiers, comment savoir, une fois lancée avec un .exe la quantité de mémoire qu'elle va occuper?

Si tu connais la taille du type, tu peux évaluer la quantité occupée à minimum taille*nombre d'éléments.

Un int (car short int est aussi un type d'entier) étant codé sur 32 bits (4 bytes) sous windows, tu peux te dire que l'allocation d'un tableau 10 000 entiers sera d'au minimum... 40 000 bytes / octets (320 000 bits)

Cela me fait me rendre compte que j'ai très mal calculé la quantité de mémoire utilisée pour représenter ton tableau de dix millions d'entiers... mais bon, ce n'est qu'un détail

A cela, il faut rajouter l'espace mémoire nécessaire pour... contenir les différentes instructions et fonctions de l'application, les autres objets et tableaux éventuels, et plein d'autres choses

Autre exemple, si tu lances deux applications Excel, la mémoire occupée sera deux fois supérieure à la mémoire occupée si tu lances une applications excel.

En moyenne oui, si les deux instances de excel manipule des données relativement semblables

Quand on développe un projet, comment connais-t-on la mémoire maximale que l'on peut allouer?

Généralement, en connaissant les limites imposées par le système et / ou l'OS sur lequel l'application devra fonctionner

Code :

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

1
2
int *pBigDataArray = new int[100000000];
int *pBigDataArray = new int[100000000];

et cela plante effectivement.

C'est bien la preuve de ce que je disais plus haut, à ceci près que tu n'a peut être pas atteint la quantité limite de mémoire disponible pour l'application, mais que tu peux parfaitement te trouver dans une situation dans laquelle il est impossible de trouver suffisamment de mémoire contigüe pour permettre de représenter deux fois dix millions d'entiers

[deubelte]

C'est bien la preuve de ce que je disais plus haut, à ceci près que tu n'a peut être pas atteint la quantité limite de mémoire disponible pour l'application, mais que tu peux parfaitement te trouver dans une situation dans laquelle il est impossible de trouver suffisamment de mémoire contigüe pour permettre de représenter deux fois dix millions d'entiers

Bizarrement, j'ai re-essayé après, et cela a fonctionné, mais ça à fait planter l'ordinateur, à un tel point que j'ai du le relancer.

Généralement, en connaissant les limites imposées par le système et / ou l'OS sur lequel l'application devra fonctionner

Je pose ces questions car je risque de développez des applic pour des banques, entre autre des logiciels, qui je pense seront utilisés sur des ordinateurs "normaux", ceux qu'on peut avoir chez soit, sûrement avec un OS comme vista ou xp.
Donc vaut mieux avoir à l'avance une idée des capacités.

[koala01]

Tu fais tout à fait fausse route en voulant te baser sur les capacités de l'ordinateur pour déterminer ce que tu peux ou ce que tu ne peux pas faire...

Il faut en effet être conscient que les capacités "brutes" de l'ordinateur sont "rognées" par tout ce qui peut tourner dessus en plus de ton application particulière, et que par conséquent tu ne disposera jamais (ou peu s'en faut) de toutes les ressources évaluées.

L'idéal est donc de veiller en permanence à n'utiliser que le stricte minimum de ressources requis et à les libérer aussitôt qu'elles ne sont plus nécessaires.

Ce sera la meilleure manière de t'assurer:

• que même les plus petites configurations seront supportées (du moins, dans une certaine mesure)
• que ton application ne fera pas tout "planter" magistralement parce que l'utilisateur aura eu le malheur de vouloir lancer son client de messagerie ou son navigateur web en même temps que ton application
• que ton application sera au final non seulement réellement utile à l'utilisateur, mais qu'il n'aura pas des sueurs froides à la seule idée de devoir la lancer
• une certaine sécurité liée à l'utilisation de ton application

C'est d'autant plus important si ton application est commandée par une banque, car les sommes mises en jeu peuvent rapidement devenir importantes