le système peut très bien tourner sainement et quand-même refuser une alloc trop grosse.
C'est ce que je dis, si l'allocation d'un gros objet échoue tu peux fermer proprement ou revenir à un état stable, suivant l'importance de l'application et de l'allocation en question. Cela est plus délicat quand l'allocation est petite (mais là encore, totu dépend du contexte).
Dans un domaine différent on peut mettre des quotas sur les processus, ça peut aussi être une raison pour lesquelles la demande de mémoire échoue, sans que le système ne soit particulièrement sous pression.
Dans ce cas c'est ton application qui n'a plus de mémoire et tu trouves un problème : tu ne peux plus avancer avec ton programme. Bien sûr ça dépend des cas, il se peut que l'allocation petite soit mineure et qu'on s'en passe et qu'il n'y a pas besoin de mémoire supplémentaire. C'est à voir, je voulais surtout dire qu'un échec d'allocation ne devait pas systématiquement être traité proprement car c'est inutile. Mais c'est au programmeur d'analyser le cas et de sortir la procédure adaptée.
[^] # Re: Oublies le C.
Posté par Renault (site web personnel) . En réponse au journal C(++) ?. Évalué à 3.
Je suis entièrement d'accord.
C'est ce que je dis, si l'allocation d'un gros objet échoue tu peux fermer proprement ou revenir à un état stable, suivant l'importance de l'application et de l'allocation en question. Cela est plus délicat quand l'allocation est petite (mais là encore, totu dépend du contexte).
Dans ce cas c'est ton application qui n'a plus de mémoire et tu trouves un problème : tu ne peux plus avancer avec ton programme. Bien sûr ça dépend des cas, il se peut que l'allocation petite soit mineure et qu'on s'en passe et qu'il n'y a pas besoin de mémoire supplémentaire. C'est à voir, je voulais surtout dire qu'un échec d'allocation ne devait pas systématiquement être traité proprement car c'est inutile. Mais c'est au programmeur d'analyser le cas et de sortir la procédure adaptée.