Es Foo * f = new Foo buen código de C++

Question

Al leer un antiguo C++ Journal que tenía, noté algo.

Uno de los artículos que se afirmaba que

Foo *f = new Foo();

era casi inaceptable profesional código C++ en general, y una solución de gestión automática de memoria era apropiado.

¿Esto es así?

editar: reformulado: ¿es la administración de memoria directa inaceptable para el nuevo código de C++, en general? ¿Debería auto_ptr (u otras envolturas de administración) usarse para el nuevo código más?

Answer 1

Este ejemplo es muy similar a Java.
En C++, solo utilizamos la gestión de memoria dinámica si es necesario.
Una mejor alternativa es simplemente declarar una variable local.

{ 
    Foo f; 

    // use f 

} // f goes out of scope and is immediately destroyed here. 

Si debe usar memoria dinámica, utilice un puntero inteligente.

// In C++14 
{ 
    std::unique_ptr<Foo> f = std::make_unique<Foo>(); // no need for new anymore 
} 

// In C++11 
{ 
    std::unique_ptr<Foo> f(new Foo); // See Description below. 
} 

// In C++03 
{ 
    std::auto_ptr<Foo> f(new Foo); // the smart pointer f owns the pointer. 
             // At some point f may give up ownership to another 
             // object. If not then f will automatically delete 
             // the pointer when it goes out of scope.. 

} 

Hay un manojo entero os punteros inteligentes proporcionados std :: int e impulso :: (ahora algunos están en std :: TR1) escoger el adecuado y utilizarlo para administrar la vida útil de su objeto.

Ver Smart Pointers: Or who owns you baby?

Técnicamente se puede utilizar la nueva/eliminar tareas de gestión de memoria.
Pero en código C++ real casi nunca se hace. Casi siempre hay una mejor alternativa para hacer la gestión de la memoria a mano.

Un ejemplo simple es std :: vector.Debajo de las cubiertas usa nuevo y eliminar. Pero nunca serías capaz de decir desde el exterior. Esto es completamente transparente para el usuario de la clase. Todo lo que el usuario sabe es que el vector tomará posesión del objeto y se destruirá cuando se destruya el vector.

Answer 2

En primer lugar, creo que debería ser Foo *f = new Foo();

Y la razón por la que no me gusta usar esa sintaxis, ya que es fácil olvidar añadir un delete al final del código y dejar su memoria una -leakin '.

Answer 3

Con algún tipo de esquema de puntero inteligente puede obtener administración de memoria automática, recuento de referencias, etc., con solo una pequeña cantidad de sobrecarga. Usted paga por eso (en memoria o en rendimiento), pero puede valer la pena pagarlo en lugar de tener que preocuparse por ello todo el tiempo.

Answer 4

Nº

Hay muy buenas razones para no utilizar sistemas automáticos de gestión de memoria en ciertos casos. Estos pueden ser el rendimiento, la complejidad de las estructuras de datos debido a referencias cíclicas, etc.

Sin embargo, recomiendo solo utilizar un generador de bits con new/malloc si tiene una buena razón para no usar algo más inteligente. Ver asignaciones desprotegidas me asusta y me hace esperar que el programador sepa lo que están haciendo.

Algún tipo de clase de puntero inteligente como boost :: shared_ptr, boost :: scoped_ptr sería un buen comienzo. (Estos serán parte del estándar C++ 0x así que no les dé miedo;))

Answer 5

En general, no, pero el caso general no es el caso común. Es por eso que los esquemas automáticos como RAII se inventaron en primer lugar.

Desde una respuesta que escribí a otra pregunta:

El trabajo de un programador es expresar cosas con elegancia en su lengua de elección.

C++ tiene una semántica muy agradable para construcción y destrucción de objetos en la pila. Si se puede asignar un recurso durante la duración de un bloque de alcance , entonces un buen programador probablemente tomará esa ruta con una resistencia mínima de . La duración del objeto es delimitada por llaves que probablemente ya estén allí, .

Si no hay una buena manera de poner el objeto directamente en la pantalla, tal vez se puede poner dentro de otro objeto como miembro . Ahora su vida útil es un poco más de , pero C++ todavía hace mucho automáticamente. La duración del objeto está delimitada por un objeto principal: se ha delegado el problema .

Puede que no haya un padre. Lo mejor es una secuencia de padres adoptivos. Esto es lo que auto_ptr es para. Todavía es bastante bueno, porque el programador debe saber qué padre particular es el propietario. La vida útil del objeto está delimitada por la duración de su secuencia de propietarios . Un paso por la cadena en determinismo y elegancia per se es shared_ptr: vida delimitada por la unión de un grupo de propietarios.

> Pero tal vez este recurso no es concurrente con cualquier otro objeto, establezca de objetos, o el flujo de control en el sistema . Se crea después de que ocurra algún evento y se destruye en otro evento . Aunque hay muchas herramientas para delimitar vidas por delegaciones y otras vidas, no son suficientes para calcular cualquier función arbitraria . Por lo que el programador podría decidir escribir una función de varias variables para determinar si un objeto se acerca a la existencia o desaparecer, y llamar a new y delete.

Finalmente, las funciones de escritura pueden ser duras. ¡Quizás las reglas que gobiernan el objeto tomarían demasiado tiempo y memoria para calcular realmente!Y es puede ser realmente difícil expresar elegantemente, volviendo a mi punto original . Entonces para eso tenemos recolección de basura: el objeto de por vida está delimitado por cuando lo quiere y cuando no lo hace.

Answer 6

Dejé de escribir este código hace algún tiempo. Existen varias alternativas: eliminación basada

Ámbito

{ 
    Foo foo; 
    // done with foo, release 
} 

scoped_ptr de ámbito basado en la asignación dinámica

{ 
    scoped_ptr<Foo> foo(new Foo()); 
    // done with foo, release 
} 

shared_ptr para las cosas que se deben manejar en muchos lugares

shared_ptr<Foo> foo; 
{ 
    foo.reset(new Foo()); 
} 
// still alive 
shared_ptr<Foo> bar = foo; // pointer copy 
... 
foo.reset(); // Foo still lives via bar 
bar.reset(); // released 

gestión de recursos basado en de Facory

Foo* foo = fooFactory.build(); 
... 
fooFactory.release(foo); // or it will be 
          // automatically released 
          // on factory destruction 

Answer 7

creo, el problema de todas estas "mejores prácticas ... ..." preguntas es que todos ellos consideran que el código fuera de contexto. Si pregunta "en general", debo admitir que la gestión directa de la memoria es perfectamente aceptable. Es sintácticamente legal y no viola ninguna semántica del lenguaje.

En cuanto a las alternativas (variables de pila, punteros inteligentes, etc.), todas tienen sus inconvenientes. Y ninguno de ellos tiene la flexibilidad, la administración de memoria directa tiene. El precio que debe pagar por dicha flexibilidad es su tiempo de depuración, y debe conocer todos los riesgos.

Answer 8

Depende de exactamente lo que queremos decir.

• ¿Nunca se debe usar new para asignar memoria? Por supuesto que debería, no tenemos otra opción. new es la forma de asignar objetos dinámicamente en C++. Cuando necesitamos asignar dinámicamente un objeto de tipo T, hacemos new T(...).
• ¿Debería llamarse newde forma predeterminada cuando queremos instanciar un objeto nuevo? NO. En java o C#, new se utiliza para crear objetos nuevos, por lo que se usa en todas partes. en C++, solo se usa para asignaciones de pila. Casi todos los objetos deben ser asignados a la pila (o creados en el lugar como miembros de la clase) para que las reglas de alcance del lenguaje nos ayuden a administrar sus tiempos de vida. new no es a menudo necesario. Por lo general, cuando queremos asignar nuevos objetos en el montón, lo hace como parte de una colección más grande, en cuyo caso debe simplemente insertar el objeto en su contenedor STL y dejar que se preocupe por asignar y desasignar la memoria. Si solo necesita un único objeto, normalmente se puede crear como un miembro de clase o una variable local, sin usar new.
• ¿Debe estar presente new en su código de lógica de negocios? Rara vez, si alguna vez. Como se mencionó anteriormente, puede y debe ser ocultado dentro de las clases de envoltura. std::vector, por ejemplo, asigna dinámicamente la memoria que necesita. Por lo tanto, el usuario del vector no tiene por qué preocuparse. Solo creo un vector en la pila, y se encarga de las asignaciones de montón para mí.Cuando un vector u otra clase de contenedor no es adecuado, podemos escribir nuestro propio contenedor RAII, que asigna algo de memoria en el constructor con new, y lo libera en el destructor. Y esa envoltura se puede asignar a la pila, por lo que el usuario de la clase nunca tiene que llamar al new.

Uno de los artículos que se afirmaba que Foo *f = new Foo(); era casi inaceptable profesional código C++ en general, y una solución de gestión automática de memoria era apropiado.

Si quieren decir lo que creo que significan, entonces tienen razón. Como dije anteriormente, new generalmente debe ocultarse en clases de contenedor, donde la administración automática de la memoria (en forma de vida del alcance y los objetos que tienen llamados a sus destructores cuando salen del alcance) puede encargarse de ello. El artículo no dice "nunca asigne nada en el montón" o nunca use new ", sino simplemente" Cuando use new, no solo almacene un puntero en la memoria asignada. Colóquelo dentro de algún tipo de clase que pueda ocuparse de liberarlo cuando se salga del alcance.

En lugar de Foo *f = new Foo();, debe utilizar uno de estos:

Scoped_Foo f; // just create a wrapper which *internally* allocates what it needs on the heap and frees it when it goes out of scope 
shared_ptr<Foo> f = new Foo(); // if you *do* need to dynamically allocate an object, place the resulting pointer inside a smart pointer of some sort. Depending on circumstances, scoped_ptr, or auto_ptr may be preferable. Or in C++0x, unique_ptr 
std::vector<Foo> v; v.push_back(Foo()); // place the object in a vector or another container, and let that worry about memory allocations. 

Answer 9

Si está utilizando excepciones que tipo de código está prácticamente garantizado para dar lugar a fugas Recource. Incluso si deshabilita las excepciones, es muy fácil deshacerse de la limpieza cuando se sincroniza manualmente con delete.

Answer 10

En general, su ejemplo no es una excepción segura y, por lo tanto, no debe utilizarse. Si la línea sigue directamente a los nuevos lanzamientos? La pila se desenrolla y acaba de filtrar la memoria. Un puntero inteligente se encargará de resolverlo como parte de la pila. Si tiende a no manejar excepciones, entonces no hay inconveniente fuera de los problemas de RAII.