Por que deveria ser usado o idioma" PIMPL"? [duplicado]

O código de exemplo deve ser distribuído por dois conjuntos de ficheiros de código. Então só a Cat.h é o arquivo que é enviado com o produto.

CatImpl.h é incluído pela Cat.cpp e CatImpl.cpp contém a implementação para CatImpl:: Purr (). Isto não será visível para o público usando o seu produto.

Tal como mencionado por outros, usando sua técnica, decupla completamente a implementação da interface do objeto. Então você não terá que recompilar tudo o que usa gato se você só quer mudar a implementação do Purr().

Esta técnica é utilizada numa metodologia denominada design by contract.

Considere que a implementação de Cat pode incluir muitos cabeçalhos, pode envolver meta-programação template que leva tempo para compilar por si só. Por que um usuário, que só quer usar o Cat tem que incluir tudo isso? Assim, todos os os arquivos são escondidos usando o idioma pimpl (daí a declaração para a frente de CatImpl), e usando a interface não obriga o usuário a incluí-los.

Estou desenvolvendo uma biblioteca para otimização não linear (leia "lots of nasty math"), que é implementada em modelos, então a maioria do código está em cabeçalhos. Leva cerca de cinco minutos para compilar (em uma CPU multi-core decente), e apenas processar os cabeçalhos em um .cpp de outra forma vazio leva cerca de um minuto. Por isso, qualquer pessoa que use a biblioteca tem de esperar um minuto. alguns minutos de cada vez que compilam o seu código, o que torna o desenvolvimento bastante aborrecido . No entanto, ao esconder a implementação e os cabeçalhos, apenas inclui um arquivo de interface simples, que compila instantaneamente.

Se a sua classe usar o idioma pimpl, pode evitar alterar o ficheiro de cabeçalho na classe pública.

Isto permite-lhe Adicionar/Remover métodos à classe pimpl, sem modificar o ficheiro de cabeçalho da classe externa. Você também pode adicionar / remover #inclui para o pimpl também.

Quando você muda o ficheiro de cabeçalho da classe externa, você tem que recompilar tudo o que #o Inclui (e se algum desses são ficheiros de cabeçalho, você tem que recompilar tudo o que #os Inclui, e assim on)

Tipicamente, a única referência à classe Pimpl no cabeçalho para a classe proprietária (Cat neste caso) seria uma declaração de avanço, como você fez aqui, porque isso pode reduzir grandemente as dependências.

Por exemplo, se a sua classe Pimpl tiver complicado a classificação como membro (e não apenas um ponteiro ou referência a ele), então terá de ter complicado a classificação completamente definida antes de ser usada. Na prática, isto significa incluir "Classe complicada".h " (que também indirectamente incluir qualquer classe complicada depende de). Isto pode levar a um único preenchimento de cabeçalho puxando em lotes e lotes de coisas, o que é ruim para gerenciar suas dependências (e seus tempos de compilação).

Quando você usa o pimpl idion, você só precisa #incluir o material usado na interface pública do seu tipo de proprietário (que seria Cat aqui). O que torna as coisas melhores para as pessoas que usam a sua biblioteca, e significa que você não precisa se preocupar com as pessoas dependendo de alguma parte interna da sua biblioteca - ou por engano, ou porque eles querem fazer algo que você não permite, então eles #definir público privado antes de incluir seus arquivos.

Se é uma classe simples, geralmente não há razão para usar um Pimpl, mas por vezes quando os tipos são bastante grandes, pode ser uma grande ajuda (especialmente em evitar longos tempos de construção) {[[2]}

Foo.h:

class Foo {
public:
    virtual ~Foo() { }
    virtual void someMethod() = 0;

    // This "replaces" the constructor
    static Foo *create();
}

Foo.cpp:

namespace {
    class FooImpl: virtual public Foo {

    public:
        void someMethod() { 
            //....
        }     
    };
}

Foo *Foo::create() {
    return new FooImpl;
}

Este padrão tem nome?

Como também programador Python e Java, gosto muito mais disto do que o idioma pImpl.

Colocar a chamada para o impl->Purr dentro do ficheiro cpp significa que, no futuro, poderá fazer algo completamente diferente sem ter de alterar o ficheiro de cabeçalho. Talvez no próximo ano eles descubram um método auxiliar que poderiam ter chamado em vez disso e assim eles podem mudar o código para chamar isso diretamente e não usar impl->Purr em tudo. (Yes, they could achieve the same thing by updating the actual impl:: Purr method as well but in that case you are stuck with an extra function call that não alcança nada além de chamar a próxima função por sua vez)

Também significa que o cabeçalho só tem definições e não tem nenhuma implementação que faça com que uma separação mais limpa, que é todo o ponto do idioma.

Usando pimpl, winsock2.h foi incluído em apenas um arquivo cpp onde eu poderia colocar uma tampa sobre o problema e não se preocupar que ele voltaria para morde-me.

Para responder a pergunta original, a vantagem que encontrei no encaminhamento de chamadas para o pimpl classe foi que o pimpl classe é a mesma que a sua classe original teria sido antes de pimpl isso, além de suas implementações não são distribuídos por 2 turmas em algumas estranhas da moda. É muito mais claro implementar o público para simplesmente avançar para a classe pimpl.

Usamos o idioma PIMPL para emular programação orientada a aspectos onde os aspectos pré, post e erro são chamados antes e depois da execução de uma função membro.

struct Omg{
   void purr(){ cout<< "purr\n"; }
};

struct Lol{
  Omg* omg;
  /*...*/
  void purr(){ try{ pre(); omg-> purr(); post(); }catch(...){ error(); } }
};

Nós também usamos ponteiro para a classe base para compartilhar diferentes aspectos entre muitas classes.

A desvantagem desta abordagem é que o Utilizador da biblioteca tem de ter em conta todos os aspectos que vão ser executados, mas só vê a sua classe. É necessário navegar na documentação para qualquer secundario.

Seria possível ter a implementação no seu próprio espaço de nomes e ter um espaço de nomes público wrapper / library para o código que o utilizador vê:

catlib::Cat::Purr(){ cat_->Purr(); }
cat::Cat::Purr(){
   printf("purrrrrr");
}

Desta forma, todo o código da biblioteca pode fazer uso do espaço de nomes do gato e como a necessidade de expor uma classe para o usuário surge um invólucro pode ser criado no espaço de nomes do catlib.

Muitas vezes pergunto-me se os" benefícios " são exagerados; Sim, você pode fazer alguns dos seus detalhes de implementação ainda mais escondidos, e sim, você pode mudar a sua implementação sem mudar o cabeçalho, mas não é óbvio que estas são grandes vantagens na realidade.