new how c++ new-operator

how - new keyword c++



¿Es útil probar el retorno de "nuevo" en C++? (6)

Por lo general, nunca veo prueba de nuevo en C ++ y me preguntaba por qué.

Foo *f = new Foo;

// f is assumed as allocated, why usually, nobody test the return of new?


  1. new throws std::bad_alloc por defecto. Si usa el valor predeterminado, la verificación de null es obsoleta, pero es necesario manejar excepciones. Este comportamiento predeterminado es coherente con el paradigma de seguridad de excepciones de C ++: generalmente proporciona que un objeto se construya o no se asigne

  2. Si anula el valor predeterminado utilizando new (std::nothrow) , es necesario verificar null. "Nuevo" asigna y compromete páginas, por lo que es posible que se quede sin memoria, ya sea porque se quedó sin descriptores de página o porque no hay memoria física disponible

  3. investiga la gestión de la memoria de tu SO. La máquina de referencia C / C ++ no sabe cómo administra su sistema operativo su sistema operativo, por lo que confiar en el lenguaje por sí solo no es seguro. Por ejemplo, si la asignación de memoria no es buena, lea sobre C malloc() + compromiso excesivo de Linux


Como se cita aquí

"En los compiladores que cumplen con el estándar ISO C ++, si no hay memoria suficiente para la asignación, el código arroja una excepción de tipo std :: bad_alloc. Todo el código subsiguiente se cancela hasta que se maneja el error en un bloque try-catch o el programa sale anormalmente. El programa no necesita verificar el valor del puntero, si no se lanzó una excepción, la asignación tuvo éxito ".


Por lo general, nadie prueba la devolución de un código nuevo porque Visual Studio ahora arroja el estilo que dice el estándar.

En el código anterior, si se ha realizado un truco para evitar tirar, es mejor que lo pruebes.


Según el estándar actual, el nuevo nunca devuelve NULL , arroja un std :: bad_alloc en su lugar. Si no desea que se ejecute nuevo (según el estándar anterior), sino que devuelva NULL, debe llamarlo postfijación con " (std :: nothrow) ". es decir

Foo* foo = new (std::nothrow) Foo;

Por supuesto, si tiene una cadena de herramientas muy vieja o posiblemente rota, es posible que no siga el estándar.


Todo depende de qué versión de C ++ se dirija al código. La especificación de c ++ desde hace mucho tiempo ha afirmado que, al menos de forma predeterminada, las fallas en new causarán una excepción de c ++, por lo que cualquier código que realice una prueba sería completamente redundante. La mayoría de la programación hoy en día también apunta a sistemas operativos de memoria virtual donde es casi imposible quedarse sin memoria, Y una condición de falta de memoria es tan fatal que dejar que la aplicación falle en el próximo acceso NULO es una buena forma de hacerlo. terminando.

Es realmente solo en la programación incrustada, donde se considera que el manejo de excepciones es demasiado alto, y la memoria es muy limitada, que los programadores se molestan en buscar nuevas fallas.


Todo depende de su complier VC ++ hasta la versión 6 da NULL si el nuevo operador falla, en una aplicación que no es MFC.

Ahora el problema se agranda cuando usas, por ejemplo, STL con VC ++ 6, porque el STL cumple con los estándares, nunca probará NULL cuando necesite obtener algo de memoria, y adivinará lo que sucederá en condiciones de poca memoria ...

Entonces, para todos los que todavía usan VC ++ 6 y STL, revisen este artículo para obtener una solución. No permita que las fallas de asignación de memoria bloqueen su aplicación STL heredada