Pimpl and Stack Assocation

Question

Así que he estado pensando en la asignación Pimpl y Stack.He estado escribiendo una biblioteca y decidí usar Pimpl para ocultar al miembro privado de la clase.Eso significa que tendría una clase declarada así

class Foo {
private:
    class Handle;
    std::tr1::shared_ptr<Handle> handle;
public:
    Foo();
};

es bastante sencillo.Pero luego en el constructor haces esto

Foo::Foo() : handle(new Handle()) {}

Entonces, cuando alguien que usa mi biblioteca crea un foo en la pila, esencialmente están haciendo una asignación de montones de todos modos.¿Es esta la compensación con la que tiene que vivir al usar Pimpl?Pensé en liberar la documentación con una advertencia junto a los constructores: "ADVERTENCIA: Esto resulta en una asignación de montones" o algo.

Mi otro pensamiento fue tener todas las clases que estén expuestas a la implementación como interfaces virtuales puras y un montón de métodos de fábrica estáticos que regresan a los punteros inteligentes.Esto también significa la asignación del montón, pero no hay truco para ello.

¿Alguna idea o sugerencia?¿Estoy siendo demasiado considerado por programadores que usan mi biblioteca?

Answer 1

¿Es esta la compensación con la que tiene que vivir cuando use PIMPL?

de manera efectiva, sí, aunque hay técnicas, como las discutidas por Herb Sutter en "la Idioma de PIMPL rápido, " que se puede usar para eliminar o acelerar la asignación del montón, al costo de mayor complejidad.

Pensé en soltar la documentación con una advertencia junto a los constructores: "Advertencia: Esto se traduce en una asignación de montones" o en Somesuch.

Solo si es necesario hacerlo (es decir, solo si sus usuarios se sorprenderían por el hecho de que su clase realizó la asignación de montones). Muchas clases realizan una asignación de montones, incluidas muchas de las personas en la biblioteca estándar de C ++ (todos los contenedores, por ejemplo).

¿Estoy siendo demasiado considerado con programadores que usan mi biblioteca?

Posiblemente :-). A menos que tenga los requisitos de alto rendimiento para su clase o usted espera que se cree y destruya instancias de que su clase sea extremadamente frecuente, no se preocupará demasiado por ello. Por supuesto, si tiene requisitos de rendimiento significativos, PIMPL puede no ser una buena opción.

Answer 2

Entonces, cuando alguien que usa mi biblioteca crea un foo en la pila, esencialmente están haciendo una asignación de montones de todos modos. ¿Es esta la compensación con la que tiene que vivir al usar Pimpl?

sí.

Pensé en soltar la documentación con una advertencia junto a los constructores: "Advertencia: Esto se traduce en una asignación de montones" o en Somesuch.

Consideraría que sobre el comentario agresivo :) Si su clase es tan crítica, tal vez debería evitar el idioma Pimpl. Si está representando un número, esto podría ser concerniente y vale la pena señalar. Si está ocultando la implementación de una conexión de base de datos, no vale la pena el comentario :)

Mi otro pensamiento fue tener todas las clases que estén expuestas a la implementación como interfaces virtuales puras y un montón de métodos de fábrica estáticos que regresan a los punteros inteligentes. Esto también significa la asignación del montón, pero no hay truco para ello.

Sí, es un poco más obvio para el usuario, pero probablemente probablemente no valga la pena sobre sí mismo.

¿Alguna idea o sugerencia? ¿Estoy siendo demasiado considerado por programadores que usan mi biblioteca?

Hay una compensación, pero si su clase es lo suficientemente compleja como para obtener realmente el Idiom de Pimpl, probablemente puedas asumir que una asignación de montones está bien. Si estaba usando tu biblioteca, probablemente no me preocupaba.