c++ - seguidores - hashtag suggestions
¿Cuándo debería usarse std:: nothrow? (9)
Como yo lo entiendo, casi nunca y ninguno.
¿Cuál es el uso ideal de std::nothrow ?
Lo usaría solo como una optimización (o simplificación de código) cuando, de lo contrario, habría puesto un bloque try-catch inmediatamente alrededor de un uso de new normal, catch std::bad_alloc .
Esta es una situación bastante rara, porque es raro poder manejar de manera útil la falta de memoria allí mismo en el sitio de la llamada. Por lo general, asigna memoria porque la necesita, no porque le gustaría tenerla sino que puede vivir sin ella. El código que pasa a los punteros nulos hace una copia de seguridad de una cadena de personas que llaman hasta que finalmente alguien puede resolver el problema no es idiomático C ++.
Sin embargo, puede ocurrir que el error se pueda manejar de inmediato. Por ejemplo, podría estar en una situación en la que usará un algoritmo o técnica con suficiente espacio de trabajo y un algoritmo o técnica diferente, más lento, sin. Entonces, de nuevo, ¿estaría asignando ese espacio de trabajo directamente con el new ? No normalmente. Y de todos modos, a veces hay que tener cuidado con ese enfoque, porque si su sistema operativo supera en exceso, en general no puede manejar la memoria sin gracia en el nivel de la aplicación.
Tenga en cuenta que una expresión que incluye std :: nothrow todavía puede generar una excepción (en particular de cualquier constructor del objeto que se asigna), por lo que solo se necesita una cosa si desea evitar lanzar una excepción. También tienes que asegurarte de que el constructor no tire.
En lo que a mí respecta, los días de los programas de C ++ que no usan excepciones en absoluto, han terminado. Supongo que si se reanudaran para mí, debido a alguna guía de estilo en particular, esa es la otra razón probable para no necesitar un nuevo.
Me imagino que esto se puede usar como una optimización de ruta rápida con asignadores personalizados; por ejemplo, fallar la solicitud actual y hacer crecer la agrupación en algún momento posterior / inactivo. Bastante un caso de la esquina.
Portar un programa en C a C ++. Su programa C tiene todos esos controles allí, después de cada malloc, y no hay noción de excepciones. Por lo tanto, es mucho más sencillo cambiar cada malloc a nuevo (en lugar de hacerlo) que envolver cada malloc en un bloque try.
Sé que había versiones anteriores de C ++ (específicamente de Microsoft) que no se lanzaban cuando no podían asignar la memoria, pero devolvían NULL. Esta sería una manera fácil de mantener la compatibilidad con el código antiguo en lugar de cambiar toda la lógica.
Solo muy pocos programas deberían asignar más de 1 GiB de memoria, y dado que los sistemas modernos sobreestiman la memoria, los new nunca volverán nulos ni se lanzarán a estos sistemas. Por lo tanto, no tiene ningún sentido verificar el valor de retorno de new / malloc. ¡Solo mantén la huella de memoria baja y deja que el asesino sin memoria derribe otros procesos!
Tal vez si su aplicación requiriera nano-optimización y no pudiera permitir la sobrecarga del manejo de excepciones, entonces tal nothrow no se necesitaría el desarrollo.
Tenga en cuenta que Stroustrup está bastante convencido de que el programador puede desactivar los gastos generales en C ++. (Sin embargo, como advertencia, solo porque tenga la opción no significa que deba hacerlo).
Utiliza std :: nothrow cuando desea tener que comprobar si hay un valor nulo después de cada nuevo. Una gran cantidad de código heredado lo necesitaba cuando se hizo la primera versión del estándar. Una gran cantidad de código heredado escrito después lo usa también porque las personas eran paranoicas de excepciones. De vez en cuando te encontrarás con alguien que todavía lo es.
Es muy raro que realmente quieras hacer esto que incluso me tomó un segundo recordar la WTF de la que hablabas.
http://www.cplusplus.com/reference/std/new/nothrow/
Esta construcción rara vez se usa, porque sospecho que realmente no afecta el rendimiento de la asignación de memoria, sino que se puede usar por conveniencia.
Aún así, la variante genérica es usualmente preferida.