Resolver erros de compilação devido à dependência circular entre classes

Costumo me encontrar em uma situação em que estou enfrentando vários erros de compilação / vinculador em um projeto C ++ devido a algumas decisões ruins de design (tomadas por outra pessoa :)) que levam a dependências circulares entre classes C ++ em diferentes arquivos de cabeçalho (também pode acontecer no mesmo arquivo) . Mas, felizmente (?), Isso não acontece com frequência suficiente para que eu lembre da solução para esse problema na próxima vez que acontecer novamente.

Portanto, para facilitar o recall no futuro, postarei um problema representativo e uma solução junto com ele. Obviamente, melhores soluções são bem-vindas.

• A.h

  class B;
  class A
  {
      int _val;
      B *_b;
  public:
  
      A(int val)
          :_val(val)
      {
      }
  
      void SetB(B *b)
      {
          _b = b;
          _b->Print(); // COMPILER ERROR: C2027: use of undefined type 'B'
      }
  
      void Print()
      {
          cout<<"Type:A val="<<_val<<endl;
      }
  };
  

• B.h

  #include "A.h"
  class B
  {
      double _val;
      A* _a;
  public:
  
      B(double val)
          :_val(val)
      {
      }
  
      void SetA(A *a)
      {
          _a = a;
          _a->Print();
      }
  
      void Print()
      {
          cout<<"Type:B val="<<_val<<endl;
      }
  };
  

• main.cpp

  #include "B.h"
  #include <iostream>
  
  int main(int argc, char* argv[])
  {
      A a(10);
      B b(3.14);
      a.Print();
      a.SetB(&b);
      b.Print();
      b.SetA(&a);
      return 0;
  }
  

A maneira de pensar sobre isso é "pensar como um compilador".

Imagine que você está escrevendo um compilador. E você vê código assim.

// file: A.h
class A {
  B _b;
};

// file: B.h
class B {
  A _a;
};

// file main.cc
#include "A.h"
#include "B.h"
int main(...) {
  A a;
}

Ao compilar o arquivo .cc (lembre-se de que o .cc e não o .h é a unidade de compilação), você precisa alocar espaço para o objeto A. Então, bem, quanto espaço então? O suficiente para guardar B! Qual é o tamanho Bentão? O suficiente para guardar A! Opa

Claramente uma referência circular que você deve quebrar.

Você pode quebrá-lo, permitindo que o compilador reserve o máximo de espaço que sabe sobre o início - ponteiros e referências, por exemplo, sempre terão 32 ou 64 bits (dependendo da arquitetura) e, portanto, se você substituir (um) por um ponteiro ou referência, as coisas seriam ótimas. Digamos que substituímos em A:

// file: A.h
class A {
  // both these are fine, so are various const versions of the same.
  B& _b_ref;
  B* _b_ptr;
};

Agora as coisas estão melhores. Um pouco. main()ainda diz:

// file: main.cc
#include "A.h"  // <-- Houston, we have a problem

#include, para todas as extensões e propósitos (se você retirar o pré-processador), basta copiar o arquivo no arquivo .cc . Então, realmente, o .cc se parece com:

// file: partially_pre_processed_main.cc
class A {
  B& _b_ref;
  B* _b_ptr;
};
#include "B.h"
int main (...) {
  A a;
}

Você pode ver por que o compilador não pode lidar com isso - ele não tem idéia do que Bé - ele nunca viu o símbolo antes.

Então, vamos falar sobre o compilador B. Isso é conhecido como declaração direta e é discutido mais adiante nesta resposta .

// main.cc
class B;
#include "A.h"
#include "B.h"
int main (...) {
  A a;
}

Isso funciona . Isso não é ótimo . Mas, nesse ponto, você deve ter uma compreensão do problema de referência circular e o que fizemos para "corrigi-lo", embora a correção seja ruim.

O motivo dessa correção é ruim porque a próxima pessoa #include "A.h"terá que declarar Bantes de poder usá-la e receberá um #includeerro terrível . Então, vamos passar a declaração para o próprio Ah .

// file: A.h
class B;
class A {
  B* _b; // or any of the other variants.
};

E em Bh , neste ponto, você pode apenas #include "A.h"diretamente.

// file: B.h
#include "A.h"
class B {
  // note that this is cool because the compiler knows by this time
  // how much space A will need.
  A _a; 
}

HTH.

Você pode evitar erros de compilação se remover as definições de método dos arquivos de cabeçalho e deixar que as classes contenham apenas as declarações de método e as declarações / definições de variáveis. As definições de método devem ser colocadas em um arquivo .cpp (como a diretriz de melhores práticas diz).

O lado negativo da solução a seguir é (supondo que você tenha colocado os métodos no arquivo de cabeçalho para incorporá-los) que os métodos não são mais incorporados pelo compilador e a tentativa de usar a palavra-chave inline produz erros de vinculador.

//A.h
#ifndef A_H
#define A_H
class B;
class A
{
    int _val;
    B* _b;
public:

    A(int val);
    void SetB(B *b);
    void Print();
};
#endif

//B.h
#ifndef B_H
#define B_H
class A;
class B
{
    double _val;
    A* _a;
public:

    B(double val);
    void SetA(A *a);
    void Print();
};
#endif

//A.cpp
#include "A.h"
#include "B.h"

#include <iostream>

using namespace std;

A::A(int val)
:_val(val)
{
}

void A::SetB(B *b)
{
    _b = b;
    cout<<"Inside SetB()"<<endl;
    _b->Print();
}

void A::Print()
{
    cout<<"Type:A val="<<_val<<endl;
}

//B.cpp
#include "B.h"
#include "A.h"
#include <iostream>

using namespace std;

B::B(double val)
:_val(val)
{
}

void B::SetA(A *a)
{
    _a = a;
    cout<<"Inside SetA()"<<endl;
    _a->Print();
}

void B::Print()
{
    cout<<"Type:B val="<<_val<<endl;
}

//main.cpp
#include "A.h"
#include "B.h"

int main(int argc, char* argv[])
{
    A a(10);
    B b(3.14);
    a.Print();
    a.SetB(&b);
    b.Print();
    b.SetA(&a);
    return 0;
}

Estou atrasado em responder isso, mas não há uma resposta razoável até o momento, apesar de ser uma pergunta popular com respostas altamente votadas ....

Prática recomendada: cabeçalhos de declaração direta

Conforme ilustrado pelo <iosfwd>cabeçalho da biblioteca Standard , a maneira correta de fornecer declarações de encaminhamento para terceiros é ter um cabeçalho de declaração de encaminhamento . Por exemplo:

a.fwd.h:

#pragma once
class A;

ah:

#pragma once
#include "a.fwd.h"
#include "b.fwd.h"

class A
{
  public:
    void f(B*);
};

b.fwd.h:

#pragma once
class B;

bh:

#pragma once
#include "b.fwd.h"
#include "a.fwd.h"

class B
{
  public:
    void f(A*);
};

Os mantenedores das bibliotecas Ae e Bdevem ser responsáveis ​​por manter seus cabeçalhos de declaração direta sincronizados com seus cabeçalhos e arquivos de implementação; por exemplo, se o mantenedor de "B" aparecer e reescrever o código para ser ...

b.fwd.h:

template <typename T> class Basic_B;
typedef Basic_B<char> B;

bh:

template <typename T>
class Basic_B
{
    ...class definition...
};
typedef Basic_B<char> B;

... a recompilação do código para "A" será acionada pelas alterações no incluído b.fwd.he deverá ser concluída de forma limpa.

Prática pobre, mas comum: para a frente declarar coisas em outras bibliotecas

Diga - em vez de usar um cabeçalho de declaração de encaminhamento, conforme explicado acima - no código a.hou em a.ccvez disso, declare- class B;se:

• se a.hou a.ccincluiu b.hmais tarde:
  • a compilação de A terminará com um erro assim que chegar à declaração / definição conflitante de B(ou seja, a alteração acima em B quebrou A e quaisquer outros clientes que abusam de declarações avançadas, em vez de trabalhar de forma transparente).
• caso contrário (se A não tiver incluído eventualmente b.h- possível se A apenas armazena / passa Bs por ponteiro e / ou referência)
  • as ferramentas de construção baseadas na #includeanálise e os carimbos de data e hora alterados do arquivo não serão reconstruídos A(e seu código dependente adicional) após a alteração para B, causando erros no tempo do link ou no tempo de execução. Se B for distribuído como uma DLL carregada em tempo de execução, o código em "A" poderá falhar ao encontrar os símbolos diferentes no tempo de execução, que podem ou não ser manipulados suficientemente bem para acionar o desligamento ordenado ou a funcionalidade reduzida aceitável.

Se o código de A tiver especializações / "características" de modelo para o antigo B, elas não terão efeito.

Coisas para lembrar:

• Isso não funcionará se class Ativer um objeto declass B como membro ou vice-versa.
• A declaração de encaminhamento é o caminho a percorrer.
• A ordem da declaração é importante (e é por isso que você está mudando as definições).
  • Se ambas as classes chamam funções da outra, é necessário mover as definições.

Leia o FAQ:

• Como posso criar duas classes que se conhecem?
• Que considerações especiais são necessárias quando declarações avançadas são usadas com objetos membros?
• Que considerações especiais são necessárias quando declarações avançadas são usadas com funções embutidas?

Certa vez, resolvi esse tipo de problema movendo todas as linhas após a definição da classe e colocando as #includepara as outras classes imediatamente antes das linhas. no arquivo de cabeçalho. Dessa forma, verifique se todas as definições + linhas estão definidas antes que as linhas sejam analisadas.

Fazendo assim, é possível ainda ter várias linhas inline nos dois (ou vários) arquivos de cabeçalho. Mas é necessário ter guardas .

Como isso

// File: A.h
#ifndef __A_H__
#define __A_H__
class B;
class A
{
    int _val;
    B *_b;
public:
    A(int val);
    void SetB(B *b);
    void Print();
};

// Including class B for inline usage here 
#include "B.h"

inline A::A(int val) : _val(val)
{
}

inline void A::SetB(B *b)
{
    _b = b;
    _b->Print();
}

inline void A::Print()
{
    cout<<"Type:A val="<<_val<<endl;
}

#endif /* __A_H__ */

... e fazendo o mesmo em B.h

Eu escrevi um post sobre isso uma vez: Resolvendo dependências circulares em c ++

A técnica básica é desacoplar as classes usando interfaces. Então, no seu caso:

//Printer.h
class Printer {
public:
    virtual Print() = 0;
}

//A.h
#include "Printer.h"
class A: public Printer
{
    int _val;
    Printer *_b;
public:

    A(int val)
        :_val(val)
    {
    }

    void SetB(Printer *b)
    {
        _b = b;
        _b->Print();
    }

    void Print()
    {
        cout<<"Type:A val="<<_val<<endl;
    }
};

//B.h
#include "Printer.h"
class B: public Printer
{
    double _val;
    Printer* _a;
public:

    B(double val)
        :_val(val)
    {
    }

    void SetA(Printer *a)
    {
        _a = a;
        _a->Print();
    }

    void Print()
    {
        cout<<"Type:B val="<<_val<<endl;
    }
};

//main.cpp
#include <iostream>
#include "A.h"
#include "B.h"

int main(int argc, char* argv[])
{
    A a(10);
    B b(3.14);
    a.Print();
    a.SetB(&b);
    b.Print();
    b.SetA(&a);
    return 0;
}

Aqui está a solução para modelos: Como lidar com dependências circulares com modelos

A pista para resolver esse problema é declarar as duas classes antes de fornecer as definições (implementações). Não é possível dividir a declaração e a definição em arquivos separados, mas você pode estruturá-los como se estivessem em arquivos separados.

O exemplo simples apresentado na Wikipedia funcionou para mim. (você pode ler a descrição completa em http://en.wikipedia.org/wiki/Circular_dependency#Example_of_circular_dependencies_in_C.2B.2B )

Arquivo '' 'a.h' '':

#ifndef A_H
#define A_H

class B;    //forward declaration

class A {
public:
    B* b;
};
#endif //A_H

Arquivo '' 'b.h' '':

#ifndef B_H
#define B_H

class A;    //forward declaration

class B {
public:
    A* a;
};
#endif //B_H

Arquivo '' 'main.cpp' '':

#include "a.h"
#include "b.h"

int main() {
    A a;
    B b;
    a.b = &b;
    b.a = &a;
}

Infelizmente, todas as respostas anteriores estão faltando alguns detalhes. A solução correta é um pouco complicada, mas esta é a única maneira de fazê-lo corretamente. E dimensiona facilmente, também lida com dependências mais complexas.

Veja como você pode fazer isso, mantendo exatamente todos os detalhes e usabilidade:

• a solução é exatamente igual à originalmente pretendida
• funções embutidas ainda embutidas
• usuários Ae Bpodem incluir Ah e Bh em qualquer ordem

Crie dois arquivos, A_def.h, B_def.h. Eles conterão apenas Aas Bdefinições de s e :

// A_def.h
#ifndef A_DEF_H
#define A_DEF_H

class B;
class A
{
    int _val;
    B *_b;

public:
    A(int val);
    void SetB(B *b);
    void Print();
};
#endif

// B_def.h
#ifndef B_DEF_H
#define B_DEF_H

class A;
class B
{
    double _val;
    A* _a;

public:
    B(double val);
    void SetA(A *a);
    void Print();
};
#endif

E então, Ah e Bh conterão isso:

// A.h
#ifndef A_H
#define A_H

#include "A_def.h"
#include "B_def.h"

inline A::A(int val) :_val(val)
{
}

inline void A::SetB(B *b)
{
    _b = b;
    _b->Print();
}

inline void A::Print()
{
    cout<<"Type:A val="<<_val<<endl;
}

#endif

// B.h
#ifndef B_H
#define B_H

#include "A_def.h"
#include "B_def.h"

inline B::B(double val) :_val(val)
{
}

inline void B::SetA(A *a)
{
    _a = a;
    _a->Print();
}

inline void B::Print()
{
    cout<<"Type:B val="<<_val<<endl;
}

#endif

Observe que A_def.h e B_def.h são cabeçalhos "particulares", usuários Ae Bnão devem usá-los. O cabeçalho público é Ah e Bh

Em alguns casos, é possível definir um método ou construtor da classe B no arquivo de cabeçalho da classe A para resolver dependências circulares envolvendo definições. Dessa forma, você pode evitar precisar colocar definições nos .ccarquivos, por exemplo, se desejar implementar uma biblioteca apenas de cabeçalho.

// file: a.h
#include "b.h"
struct A {
  A(const B& b) : _b(b) { }
  B get() { return _b; }
  B _b;
};

// note that the get method of class B is defined in a.h
A B::get() {
  return A(*this);
}

// file: b.h
class A;
struct B {
  // here the get method is only declared
  A get();
};

// file: main.cc
#include "a.h"
int main(...) {
  B b;
  A a = b.get();
}

Infelizmente não posso comentar a resposta de geza.

Ele não está apenas dizendo "apresentar declarações em um cabeçalho separado". Ele diz que você deve aplicar cabeçalhos de definição de classe e definições de função embutida em diferentes arquivos de cabeçalho para permitir "dependências adiadas".

Mas sua ilustração não é realmente boa. Como as duas classes (A e B) precisam apenas de um tipo incompleto (campos / parâmetros do ponteiro).

Para entender melhor, imagine que a classe A tem um campo do tipo B e não B *. Além disso, as classes A e B desejam definir uma função embutida com parâmetros do outro tipo:

Este código simples não funcionaria:

// A.h
#pragme once
#include "B.h"

class A{
  B b;
  inline void Do(B b);
}

inline void A::Do(B b){
  //do something with B
}

// B.h
#pragme once
class A;

class B{
  A* b;
  inline void Do(A a);
}

#include "A.h"

inline void B::Do(A a){
  //do something with A
}

//main.cpp
#include "A.h"
#include "B.h"

Isso resultaria no seguinte código:

//main.cpp
//#include "A.h"

class A;

class B{
  A* b;
  inline void Do(A a);
}

inline void B::Do(A a){
  //do something with A
}

class A{
  B b;
  inline void Do(B b);
}

inline void A::Do(B b){
  //do something with B
}
//#include "B.h"

Esse código não é compilado porque o B :: Do precisa de um tipo completo de A, definido posteriormente.

Para certificar-se de que ele compila o código fonte, fique assim:

//main.cpp
class A;

class B{
  A* b;
  inline void Do(A a);
}

class A{
  B b;
  inline void Do(B b);
}

inline void B::Do(A a){
  //do something with A
}

inline void A::Do(B b){
  //do something with B
}

Isso é exatamente possível com esses dois arquivos de cabeçalho para cada classe que precisa definir funções embutidas. O único problema é que as classes circulares não podem apenas incluir o "cabeçalho público".

Para resolver esse problema, gostaria de sugerir uma extensão de pré-processador: #pragma process_pending_includes

Esta diretiva deve adiar o processamento do arquivo atual e concluir todas as inclusões pendentes.