Почему он говорит & ldquo; необъявленный идентификатор & rdquo ;? [Дубликат]

К сожалению, во всех предыдущих ответах отсутствуют некоторые детали. Правильное решение немного громоздко, но это единственный способ сделать это правильно.

Вот как вы можете это сделать, точно сохраняя все детали и удобство использования:

• решение в точности соответствует такие же, как изначально предназначенные
• встроенные функции, все еще встроенные
• пользователи A и B могут включать Ah и Bh в любом порядке

Создайте два файла: A_def.h, B_def.h. Они будут содержать только определения A и B:

// 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

И тогда, Ah и Bh будут содержать это:

// 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

Обратите внимание, что A_def .h и B_def.h являются «частными» заголовками, пользователи A и B не должны их использовать. Общий заголовок - A.h и B.h.

Замечания:

• Это не сработает, если class A имеет объект class B в качестве члена или наоборот.
• Переслать декларацию - это путь.
• Применяется порядок декларирования (именно поэтому вы выходите из определений). Если оба класса называют функции другого, вы должны перенести определения.

Читайте FAQ:

• Как я могу создать два класса, которые оба знают друг о друге?
• Какие особые соображения необходимы, если декларации прямого доступа используются с объектами-членами?
• Какие особые соображения необходимы, когда форвардные объявления используются с встроенными функциями?

Простой пример, представленный в Википедии, работал для меня. (вы можете прочитать полное описание в http://en.wikipedia.org/wiki/Circular_dependency#Example_of_circular_dependencies_in_C.2B.2B )

Файл '' 'a.h' ':

#ifndef A_H
#define A_H

class B;    //forward declaration

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

Файл' '' b.h '' ':

#ifndef B_H
#define B_H

class A;    //forward declaration

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

Файл' '' main.cpp '' ':

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

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

Вы можете избежать ошибок компиляции, если вы удалите определения метода из файлов заголовков и пусть классы содержат только декларации методов и объявления / определения переменных. Определения методов должны быть помещены в файл .cpp (как говорится в рекомендациях по лучшей практике).

Нижняя сторона следующего решения (при условии, что вы поместили методы в файле заголовка, чтобы встроить их), что методы больше не встроены в компилятор, и попытка использования ключевого слова inline создает компоновщик ошибки.

//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;
}

Вот решение для шаблонов: Как обрабатывать круговые зависимости с шаблонами

Ключ к решению этой проблемы состоит в том, чтобы объявить оба класса до предоставления определений (реализаций). Невозможно разбить объявление и определение на отдельные файлы, но вы можете структурировать их так, как если бы они были в отдельных файлах.

Я опоздал с ответом на этот вопрос, но на данный момент нет ни одного разумного ответа, несмотря на то, что это популярный вопрос с высокоподдерживаемыми ответами ....

Лучшая практика: вперед Заголовки заголовков

Как проиллюстрировано заголовком <iosfwd> стандартной библиотеки, правильный способ предоставления форвардных объявлений для других должен иметь заголовок forward declare . Например:

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*);
};

Составители библиотек A и B должны отвечать за сохранение заголовков своих прямых деклараций в соответствии с их заголовками и файлами реализации, поэтому - для Например, если сопровождающий «B» входит и перезаписывает код, который должен быть ...

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;

... тогда перекомпиляция кода для «А» будет вызвана изменениями к включенному b.fwd.h и должна завершиться чисто.

Плохая, но обычная практика: вперед объявить материал в других libs

Произнести - вместо использования заголовка прямого объявления, как описано выше, - код в a.h или a.cc вместо forward-declares class B;:

• , если a.h или a.cc позже включили b.h: компиляция A завершится с ошибкой после того, как она попадет в противоречивую декларацию / определение B (т. е. вышеуказанное изменение на B сломало A и любое другой c лижет злоупотребление форвардными декларациями, вместо того, чтобы работать прозрачно).
• в противном случае (если A в конечном итоге не включал b.h - возможно, если A просто хранит / передает Bs с помощью указателя и / или ссылки), инструменты построения, основанные на анализе #include и измененные временные метки файлов, t перестроить A (и его далее зависимый код) после изменения на B, вызывая ошибки во время соединения или времени выполнения. Если B распределяется как загруженная DLL во время выполнения, код в «A» может не отображать символы с разными причинами во время выполнения, которые могут обрабатываться или не обрабатываться достаточно хорошо, чтобы инициировать упорядоченное завершение работы или приемлемую сокращенную функциональность.

Если код А имеет специализированные шаблоны / «признаки» для старого B, они не вступят в силу.