А>Зачем несколько раз?
А>

А>//b.h
А>class A;
А>typedef A AAA;
А>class B{
А>//use AAA
А>};

А>class B;
А>typedef B BBB;
А>//a.h
А>class A{
А>//use BBB
А>};
А>

А появится класс С, который тоже хочет с ААА поработать!? Понятно что не проблема еще раз написать и это работает, но просто не красиво как-то одно и тоже несколько раз писать в разных местах...

Здравствуйте, Анатолий Широков, Вы писали:

АШ>У меня был тоже пример. Хорошо, вот пример из моей практики:

АШ>
АШ>

АШ>class Object
АШ>{
АШ>public:
АШ>   virtual ~Object() {}
АШ>   virtual void draw(Context &) = 0;
АШ>};

АШ>// корабль
АШ>//
АШ>class Ship : public Object
АШ>{
АШ>public:
АШ>};

АШ>class Order;

АШ>// позиция в ордере - посредник по сути между ордером и кораблем
АШ>//
АШ>class OrderPosition : public Ship
АШ>{
АШ>public:
АШ>   OrderPosition(Order* order, double distance, double couse_angle)
АШ>      : _owner(order), _ship(0), _distance(distance), _cours_eangle(0) 
АШ>   {
АШ>   }

АШ>   void draw(Context &c)
АШ>   {
АШ>       _ship->draw(c);
АШ>   }

АШ>private:
АШ>   Order* _owner; // он мне нужен, поскольку позиция не обладает информацией о тот кто является уравнителем, какой целевой курс - это информация более высокого уровня
АШ>   Ship* _ship;
АШ>   double _distance;
АШ>   double _course_angle;
АШ>};

АШ>// ордер - группа кораблей (каждый корабль имеет строго регламентированный порядок)
АШ>//
АШ>class Order : public Object
АШ>{
АШ>public:
АШ>   ... 
АШ>};
АШ>

АШ>К чему это я все? — много задач хороших и разных


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

Но если важен результат, то в принципе его можно достичь и таким образом.

V>Похоже, пару уроков по проэктированию тебе бы не помешало.
V>Как то все криво...

Вот так просто, без аргументов

Здравствуйте, Анатолий Широков, Вы писали:

V>>Похоже, пару уроков по проэктированию тебе бы не помешало.
V>>Как то все криво...

АШ>Вот так просто, без аргументов

Читай в этой же теме от анонима...

Простота — залог успеха...

V>>>Похоже, пару уроков по проэктированию тебе бы не помешало.
V>>>Как то все криво...
Никто и не говорит что это правильно. Тогда скажи как зная В получить А? Или типа такого вопроса даже возникать не должно?

Здравствуйте, Andrewsha, Вы писали:

V>>>>Похоже, пару уроков по проэктированию тебе бы не помешало.
V>>>>Как то все криво...
A>Никто и не говорит что это правильно. Тогда скажи как зная В получить А?

Если ты сам в класс B не передашь информацию о классе A, то она там не появится, уже такого плана был ответ от Анатолия типа такого:

class A;
class B
{
public:
B(A* _a);
~B();
};

class A
{
list<B> list_of_B;
public:
A();
...
~A();
};

Или типа такого вопроса даже возникать не должно?

Если надо значит надо...

V>Читай в этой же теме от анонима...

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

Кстати, ничего предосудительного от Анонима я по этому поводу не нашел.

A>Какие существуют методы, правильные пути решения данной задачи?

Попробую еще раз:

// object.h
//
#ifndef object_h
#define object_h

class controller;
class object 
{
    friend class controller;
public:
    object(controller &owner);

    virtual void destroy();
protected:
    virtual ~object() {}

    controller& _owner;
}; // class object 

#endif

// controller.h
//
#ifndef controller_h
#define controller_h

#include <list>
#include "object.h"

class controller
{
public:
    typedef std::list<object *> collection;

    ~controller();

    //    интерфейс для объектов
    //
    void reg(object *);
private:
    collection _objects;
};

#endif

// object.cpp
//
#include "object.h"
#include "controller.h"

object::object(controller &owner) : _owner(owner)
{
    _owner.reg(this);
}

void object::destroy()
{
    delete this;
}
// controller.cpp
//
#include <algorithm>
#include "controller.h"

namespace
{
    void delete_object(object *ptr)
    {
        ptr->destroy();
    }
}

controller::~controller()
{
    std::for_each(_objects.begin(), _objects.end(), delete_object);
}

void controller::reg(object *ptr)
{
    if(ptr && &(ptr->_owner) == this)
    {
        _objects.push_back(ptr);
    }
}

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

int main()
{
    controller c;

    object* a = new object(c);
    object* b = new object(c);

    return 0;
}

АШ>Попробую еще раз:


Понял. Имеется ввиду, что если надо чтобы ссылались друг на друга, то здесь приводится пример того, как это корректно сделать?

A>Понял. Имеется ввиду, что если надо чтобы ссылались друг на друга

Чтобы ссылаться друг на друга достаточно forward declaration.

>здесь приводится пример того, как это корректно сделать?

Ты должен понимать, что все зависит от задачи.

зы: лишнее можно не цитировать.

Здравствуйте, Аноним, Вы писали:

А>А ЗАЧЕМ ЭТО ВООБЩЕ НАДО?
Свежо в памяти, пример из Делфи.
Класс TDataSource работает с набором данных.
Классы TDBEdit, TDBGrid и другие цепляются к TDataSource и отвечают за отображение данных (так называемые Дата контролы). У них есть поле типа TDataSource.
Когда же происходит изменение набора данных TDataSource должен уведомить все дата контролы о том что данные изменились.
Налицо наличие двусторонней связи!

Здравствуйте, Andrewsha, Вы писали:

A>Всем привет!
A>Нужно сделать следующее:
A>Имеется несколько экземпляров класса А.
A>Класс А может собержать список экземпляров класса В.
A>Как зная В определить получить ссылку на А, который этот В держит в списке?

A>Проблема в том, что если класс А описывается в файле "А.h", а класс В в "В.h", то компилятор не позволяет чтобы они ссылались друг на друга.
A>Какие существуют методы, правильные пути решения данной задачи?

можно сделать так:

Здравствуйте, Andrewsha, Вы писали:

A>Всем привет!
A>Нужно сделать следующее:
A>Имеется несколько экземпляров класса А.
A>Класс А может собержать список экземпляров класса В.
A>Как зная В определить получить ссылку на А, который этот В держит в списке?

A>Проблема в том, что если класс А описывается в файле "А.h", а класс В в "В.h", то компилятор не позволяет чтобы они ссылались друг на друга.
A>Какие существуют методы, правильные пути решения данной задачи?

можно сделать так:
a.h
class A
{

}

b.h
class A
class B
{
A *x;
}

например

Здравствуйте, Andrewsha, Вы писали:

A>Здравствуйте, Аноним, Вы писали:

А>>А ЗАЧЕМ ЭТО ВООБЩЕ НАДО?
A>Свежо в памяти, пример из Делфи.
A>Класс TDataSource работает с набором данных.
A>Классы TDBEdit, TDBGrid и другие цепляются к TDataSource и отвечают за отображение данных (так называемые Дата контролы). У них есть поле типа TDataSource.
A>Когда же происходит изменение набора данных TDataSource должен уведомить все дата контролы о том что данные изменились.
A>Налицо наличие двусторонней связи!

Для этого существуют Events!!!

Здравствуйте, Valcomer, Вы писали:

V>Здравствуйте, Andrewsha, Вы писали:

A>>Здравствуйте, Аноним, Вы писали:

А>>>А ЗАЧЕМ ЭТО ВООБЩЕ НАДО?
A>>Свежо в памяти, пример из Делфи.
A>>Класс TDataSource работает с набором данных.
A>>Классы TDBEdit, TDBGrid и другие цепляются к TDataSource и отвечают за отображение данных (так называемые Дата контролы). У них есть поле типа TDataSource.
A>>Когда же происходит изменение набора данных TDataSource должен уведомить все дата контролы о том что данные изменились.
A>>Налицо наличие двусторонней связи!

V>Для этого существуют Events!!!

TDBGrid по сути является контейнером для TDataSource, и TDataSource без понятия какой такой TDBGrid его юзает, он просто генерирует событие что он изменил данные, на что TDBGrid как-то реагирует. Вот и все...

P.S. А если бы ты сам решил написать свой TDBGrid, что тогда делать? Как бы TDataSource узнал бы о твоем TDBGrid-е, пришлось бы какой-то общий интерфейс для всех TDBGrid-ov делать..., от которого user-ские TDBGrid-ы наследовались...

Здравствуйте, Valcomer, Вы писали:

<skipped>

Разве оверквотить так необходимо?

Здравствуйте, Andrewsha, Вы писали:

<skipped>

Разве оверквотить так необходимо?