PIMPL e alocação de pilha

Question

Então, estive pensando em PIMPL e alocação de pilha.Estou escrevendo uma biblioteca e decidi usar PIMPL para ocultar o membro privado da classe.Isso significa que eu teria uma classe declarada assim

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

É bastante simples.Mas então no construtor você faz isso

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

Portanto, quando alguém usando minha biblioteca cria um Foo na pilha, ele está essencialmente fazendo uma alocação de heap de qualquer maneira.É esta a compensação com a qual você tem que conviver ao usar o PIMPL?Pensei em liberar a documentação com um aviso próximo aos construtores:"AVISO:Isso resulta em uma alocação de heap" ou algo assim.

Meu outro pensamento era ter todas as classes expostas à implementação como interfaces virtuais puras e um monte de métodos de fábrica estáticos retornando ponteiros inteligentes.Isso também significa alocação de heap, mas não há nenhum truque para isso.

Alguma idéia ou sugestão?Estou sendo excessivamente atencioso com os programadores que usam minha biblioteca?

Answer 1

É esta a compensação com a qual você tem que conviver ao usar o PIMPL?

Efetivamente, sim, embora existam técnicas, como as discutidas por Herb Sutter em "O idioma Fast Pimpl," que pode ser usado para eliminar ou acelerar a alocação de heap, ao custo de maior complexidade.

Pensei em liberar a documentação com um aviso próximo aos construtores:"AVISO:Isso resulta em uma alocação de heap" ou algo assim.

Somente se for necessário (ou seja, somente se seus usuários ficarem surpresos com o fato de sua classe ter realizado a alocação de heap).Muitas classes realizam alocação de heap, incluindo muitas daquelas na biblioteca padrão C++ (todos os contêineres, por exemplo).

Estou sendo excessivamente atencioso com os programadores que usam minha biblioteca?

Possivelmente :-).A menos que você tenha requisitos de alto desempenho para sua classe ou espere que instâncias de sua classe sejam criadas e destruídas com extrema frequência, eu não me preocuparia muito com isso.Claro, se você tiver requisitos de desempenho significativos, o pimpl pode não ser uma boa escolha.

Answer 2

Portanto, quando alguém usando minha biblioteca cria um Foo na pilha, ele está essencialmente fazendo uma alocação de heap de qualquer maneira.É esta a compensação com a qual você tem que conviver ao usar o PIMPL?

Sim.

Pensei em liberar a documentação com um aviso próximo aos construtores:"AVISO:Isso resulta em uma alocação de heap" ou algo assim.

Eu consideraria isso um comentário agressivo :) Se sua classe é tão crítica para o desempenho, talvez você deva evitar o idioma PIMPL.Se você estiver representando um número, isso pode ser preocupante e digno de nota.Se você está escondendo a implementação de uma conexão de banco de dados, não vale a pena comentar :)

Meu outro pensamento era ter todas as classes expostas à implementação como interfaces virtuais puras e um monte de métodos de fábrica estáticos retornando ponteiros inteligentes.Isso também significa alocação de heap, mas não há nenhum truque para isso.

Sim, é um pouco mais óbvio para o usuário, mas provavelmente não vale a pena se preocupar.

Alguma idéia ou sugestão?Estou sendo excessivamente atencioso com os programadores que usam minha biblioteca?

Há uma compensação, mas se sua classe for complexa o suficiente para realmente ganhar com o idioma pimpl, você provavelmente poderá presumir que uma alocação de heap está OK.Se eu estivesse usando sua biblioteca, provavelmente não me preocuparia.