Modismo Pimpl sin usar la asignación de memoria dinámica

Question 1

queremos usar el idioma pimpl para ciertas partes de nuestro proyecto. Estas partes del proyecto también resultan ser partes donde la asignación de memoria dinámica está prohibida y esta decisión no está bajo nuestro control.

Entonces, lo que estoy preguntando es, ¿existe una forma limpia y agradable de implementar el idioma pimpl sin asignación de memoria dinámica?

Editar
Aquí hay algunas otras limitaciones: plataforma integrada, estándar C ++ 98, sin bibliotecas externas, sin plantillas.

Question 2

Advertencia: el código aquí solo muestra el aspecto de almacenamiento, es un esqueleto, no se ha tenido en cuenta ningún aspecto dinámico (construcción, copia, movimiento, destrucción).

Sugeriría un enfoque utilizando la nueva clase C++ 0x aligned_storageque está diseñado precisamente para tener almacenamiento en bruto.

// header
class Foo
{
public:
private:
  struct Impl;

  Impl& impl() { return reinterpret_cast<Impl&>(_storage); }
  Impl const& impl() const { return reinterpret_cast<Impl const&>(_storage); }

  static const size_t StorageSize = XXX;
  static const size_t StorageAlign = YYY;

  std::aligned_storage<StorageSize, StorageAlign>::type _storage;
};

En la fuente, luego implementa un control:

struct Foo::Impl { ... };

Foo::Foo()
{
  // 10% tolerance margin
  static_assert(sizeof(Impl) <= StorageSize && StorageSize <= sizeof(Impl) * 1.1,
                "Foo::StorageSize need be changed");
  static_assert(StorageAlign == alignof(Impl),
                "Foo::StorageAlign need be changed");
  /// anything
}

De esta forma, aunque tendrás que cambiar la alineación inmediatamente (si es necesario), el tamaño solo cambiará si el objeto cambia demasiado.

Y obviamente, dado que el cheque está en tiempo de compilación, no te lo puedes perder 🙂

Si no tiene acceso a las funciones de C++0x, hay equivalentes en el espacio de nombres TR1 para aligned_storage y alignof y hay macros implementaciones de static_assert.

Question 3

pimpl se basa en punteros y puede configurarlos en cualquier lugar donde se asignen sus objetos. También puede ser una tabla estática de objetos declarados en el archivo cpp. El punto principal de pimpl es mantener las interfaces estables y ocultar la implementación (y sus tipos usados).

Question 4

Ver El idioma rápido de la espinilla y La alegría de las espinillas sobre el uso de un asignador fijo junto con el modismo pimpl.

Question 5

Si puede usar boost, considere boost::optional<>. Esto evita el costo de la asignación dinámica, pero al mismo tiempo, su objeto no se construirá hasta que lo considere necesario.

Question 6

Una forma sería tener un char[] matriz en su clase. Hágalo lo suficientemente grande para que quepa su Impl, y en su constructor, cree una instancia de su Impl en su arreglo, con una ubicación nueva: new (&array[0]) Impl(...).

También debe asegurarse de no tener ningún problema de alineación, probablemente al tener su char[] array un miembro de un sindicato. Esto:

union { char array[xxx]; int i; double d; char *p; };

por ejemplo, se asegurará de que la alineación de array[0] será adecuado para un int, doble o un puntero.

Question 7

El objetivo de usar pimpl es ocultar la implementación de su objeto. Esto incluye el Talla del verdadero objeto de implementación. Sin embargo, esto también hace que sea incómodo evitar la asignación dinámica: para reservar suficiente espacio de pila para el objeto, debe saber qué tan grande es el objeto.

La solución típica es, de hecho, utilizar la asignación dinámica y pasar la responsabilidad de asignar suficiente espacio a la implementación (oculta). Sin embargo, esto no es posible en su caso, por lo que necesitaremos otra opción.

Una de esas opciones es usar alloca(). Esta función poco conocida asigna memoria en la pila; la memoria se liberará automáticamente cuando la función salga de su alcance. Esto no es C++ portátilsin embargo, muchas implementaciones de C++ lo admiten (o una variación de esta idea).

Tenga en cuenta que debe asignar sus objetos pimpl’d usando una macro; alloca() debe invocarse para obtener la memoria necesaria directamente de la función propietaria. Ejemplo:

// Foo.h
class Foo {
    void *pImpl;
public:
    void bar();
    static const size_t implsz_;
    Foo(void *);
    ~Foo();
};

#define DECLARE_FOO(name) \
    Foo name(alloca(Foo::implsz_));

// Foo.cpp
class FooImpl {
    void bar() {
        std::cout << "Bar!\n";
    }
};

Foo::Foo(void *pImpl) {
    this->pImpl = pImpl;
    new(this->pImpl) FooImpl;
}

Foo::~Foo() {
    ((FooImpl*)pImpl)->~FooImpl();
}

void Foo::Bar() {
    ((FooImpl*)pImpl)->Bar();
}

// Baz.cpp
void callFoo() {
    DECLARE_FOO(x);
    x.bar();
}

Esto, como puede ver, hace que la sintaxis sea bastante incómoda, pero logra un análogo de grano.

Si puede codificar el tamaño del objeto en el encabezado, también existe la opción de usar una matriz de caracteres:

class Foo {
private:
    enum { IMPL_SIZE = 123; };
    union {
        char implbuf[IMPL_SIZE];
        double aligndummy; // make this the type with strictest alignment on your platform
    } impl;
// ...
}

Esto es menos puro que el enfoque anterior, ya que debe cambiar los encabezados siempre que cambie el tamaño de la implementación. Sin embargo, le permite usar la sintaxis normal para la inicialización.

También podría implementar una pila de sombra, es decir, una pila secundaria separada de la pila normal de C++, específicamente para contener objetos pImpl’d. Esto requiere una gestión muy cuidadosa, pero, debidamente envuelto, debería funcionar. Este tipo de está en la zona gris entre la asignación dinámica y estática.

// One instance per thread; TLS is left as an exercise for the reader
class ShadowStack {
    char stack[4096];
    ssize_t ptr;
public:
    ShadowStack() {
        ptr = sizeof(stack);
    }

    ~ShadowStack() {
        assert(ptr == sizeof(stack));
    }

    void *alloc(size_t sz) {
        if (sz % 8) // replace 8 with max alignment for your platform
            sz += 8 - (sz % 8);
        if (ptr < sz) return NULL;
        ptr -= sz;
        return &stack[ptr];
    }

    void free(void *p, size_t sz) {
        assert(p == stack[ptr]);
        ptr += sz;
        assert(ptr < sizeof(stack));
    }
};
ShadowStack theStack;

Foo::Foo(ShadowStack *ss = NULL) {
    this->ss = ss;
    if (ss)
        pImpl = ss->alloc(sizeof(FooImpl));
    else
        pImpl = new FooImpl();
}

Foo::~Foo() {
    if (ss)
        ss->free(pImpl, sizeof(FooImpl));
    else
        delete ss;
}

void callFoo() {
    Foo x(&theStack);
    x.Foo();
}

Con este enfoque, es fundamental asegurarse de NO utilizar la pila de sombra para los objetos en los que el objeto contenedor está en el montón; esto violaría la suposición de que los objetos siempre se destruyen en el orden inverso al de la creación.

Question 8

Una técnica que he usado es un envoltorio pImpl no propietario. Esta es una opción muy especial y no es tan segura como el pimpl tradicional, pero puede ayudar si el rendimiento es una preocupación. Puede requerir una nueva arquitectura para que sea más funcional, como API.

Puede crear una clase pimpl que no sea propietaria, siempre que pueda (algo) garantizar que el objeto pimpl de la pila sobrevivirá al contenedor.

por ej.

/* header */
struct MyClassPimpl;
struct MyClass {
    MyClass(MyClassPimpl& stack_object); // Initialize wrapper with stack object.

private:
    MyClassPimpl* mImpl; // You could use a ref too.
};


/* in your implementation code somewhere */

void func(const std::function<void()>& callback) {
    MyClassPimpl p; // Initialize pimpl on stack.

    MyClass obj(p); // Create wrapper.

    callback(obj); // Call user code with MyClass obj.
}

El peligro aquí, como la mayoría de los contenedores, es que el usuario almacena el contenedor en un ámbito que sobrevivirá a la asignación de la pila. Úselo bajo su propio riesgo.

¿Ha sido útil esta solución?