Discussion :

[zenux]

Bonjour,

A chaque fois que il y a un "new" dans un programme, faut-il mettre un "catch(std::bad_alloc)" ?

J'ai fait ce prog:

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
#include <iostream>
using namespace std;
 
int main()
{
	int *p;
	try
	{
		while(1)
		{
			p = new int[3000];
		}
	}catch(bad_alloc)
	{
		cout<<"plus de memoire"<<endl;
	}
	return 0;
}

Voici le résultat sur linux:
localhost:/home/zenux# ./a.out
Processus arrêté

Il ne m'a même pas affiché "plus de mémoire" !!!

Merci...

[Médinoc]

En théorie, oui.

Tu peux aussi utiliser ceci:

Code :

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

1
2
3
#include <new>
[snip]
	p = new(std::nothrow) int[3000];

Et là, le new(std::nothrow) retournera NULL au lieu de lancer une exception.
Par contre, je déconseillerais cela pour les objets disposant de constructeurs. À ce moment-là, autant garder le new normal, et ainsi traiter les exceptions pouvant être lancées par le new ou par le constructeur...

[Jean-Marc.Bourguet]

L'implementation jette un std::bad_alloc quand elle detecte qu'il n'y a pas assez de memoire pour honorer la requete. Le probleme est que certains OS mentent aux process et leur disent qu'il y a de la memoire disponible quand il n'y en a pas (jouant sur le fait que certains demandent plus qu'ils n'en ont besoin).

Linux est dans ce cas, mais c'est configurable (chercher overcommit, malheureusement ce n'est pas configurable process par process ce qui serait la chose sensee a faire). Et il me semble que le defaut depuis plusieurs annees est de ne pas l'autorise.

Utiliser new(nothrow) ne change rien a ce probleme, ca ne change que la maniere dont le manque de memoire est reporte au programme. Dans le cas de l'overcommit, le resultat de new(nothrow) ne sera pas NULL, meme si en pratique il n'y a plus de memoire.

Une possibilite a envisager aussi, c'est que le manque de memoire empeche cout << "" de faire correctement son boulot.

[Sylvain Togni]

Existe-t-il une façon propre de gérer le manque de mémoire, alors ?

[Jean-Marc.Bourguet]

Existe-t-il une façon propre de gérer le manque de mémoire, alors ?

Si l'OS fait de l'overcommit, non.

Si l'OS n'en fait pas, tu devrais pouvoir compter sur std::bad_alloc et new(nothrow) sauf a avoir une vieille implementation.

Il reste a savoir ce que tu peux faire une fois que le manque de memoire est detecte. Tout ce qui peut allouer de la memoire -- dont les exceptions et les IO -- est a risque. Une technique possible pour mitiger ce risque est d'allouer de la memoire dans cette eventualite et de la liberer au debut de ton gestionnaire de manque de memoire.

[loufoque]

A chaque fois que il y a un "new" dans un programme, faut-il mettre un "catch(std::bad_alloc)" ?

Non.
Tu n'es pas obligé de récupérer toutes les exceptions. Fais le uniquement si tu as une manière utile de gérer l'erreur. Ce qui n'arrive en général pas dans la même portée, tu n'as pas suffisamment de contexte.

[uriotcea]

Il me semble qu'une methode sur pour vérifier l'allocation dynamique est de faire cela:

double *a=new double [1000];
a[999]=0;

en cas de non allocation ca génére une exception EaccessViloation

[Jean-Marc.Bourguet]

Il me semble qu'une methode sur pour vérifier l'allocation dynamique est de faire cela:

double *a=new double [1000];
a[999]=0;

en cas de non allocation ca génére une exception EaccessViloation

Il faut accéder à tout, ou du moins à chaque unité d'allocation de l'OS. Ceux-ci en effet allouent par pages ou par petit groupe de pages.

[loufoque]

en cas de non allocation ca génére une exception EaccessViloation

Sur windows uniquement.
La plupart des systèmes d'exploitation n'ont pas de système d'exception. Tu as simplement un comportement indéfini.