Вот такая ситуация:

- есть большой гипотетический массив, который надо создать динамически.
- элементы массива - объекты некоторого класса А.
- есть класс В, объект которого надо привязать к объекту класса А, при этом объекту класса А надо привязать этот объект В (если логически, то объект В надо "поставить" на массив А так, чтобы при обращении к В можно было быстро определить, на каком объекте класса А он стоит, а тыкнув в объект класса А, можно было понять, что на нём "стоит" объект В)

начнём с последнего, логично сделать 2 shared_ptr или у А weak_ptr, а B - shared_ptr.
в таком случае, нам нужно сделать массив, состоящий из shared_ptr-ов на класс А.
в таком случае, если массив большой, это накладно по ресурсам. Ну даже, не столько накладно, сколько: не пойму, правильно ли вообще так делать? По ресурсам это +8 байт. Ну и ещё, если делать всё правильно, нужен безопасный контейнер, например vector, а емплейсить в вектор большое количество объектов долго, дольше, чем вызвать new с неявным конструктором на все элементы. Почитал немного статьи, пишут, что в случае больших массивов надо брать boost::shared_array. В стандарте такого ничего нет. Как правильнее сделать? Пока думаю vector<shared_ptr<СА>>

alex_kЕсли это вектор(или массив) - может быть хранить индексы элементов? Даже если(не дай бог, конечно) произойдет переаллокация массива, индексы не испортятся :)я тоже так думал, когда у меня был просто массив shared_ptr<A[]>, и хранить shared_ptr<A> на элемент этого массива - нехорошо. Поэтому было решено в таком случае хранить индекс.
д0kА какое соотношение количества обьектов класса А и класса В ? А - десятки тысяч, В - единицы.
д0kВ общем случае если В не один, есть подозрение что таки да.
создается класс
в который в раздел приват запихивается массив класса А
и массив класса В. Так и есть уже, только массив А не один, их несколько, они напиханы в иерархическое дерево, это дерево приватно в том самом классе. Но это неважно, можно считать, что это всё один массив.
д0kТуда же запихивается map который ищет нужный
класс В по свойствам , а shared_ptr -ы на связанную пару
возвращаются интрефейсной функцией на лету.

А и В не содержат никакой информации к кому они привязаны.
а map содержит только действительные существующие связи. Интересный вариант... а почему именно через мапу? Объекты класса А могут легко содержать shared_ptr на В.
Тут немного надо объяснить, как всё устроено:
Есть 2 функционала:
1. Работает с тем самым иерархическим деревом, ведёт обработку объектов класса А по требованию: выдаёт всю инфу по объекту, в т.ч. указатель на В, с этим всё ок.
2. Работает со списком объектов класса В. По требованию должен показать положение объекта класса В "в" массиве класса А. Позиция/лист в дереве сейчас запоминается в В как второй указатель(будем все shared_ptr звать указателями, weak-слабыми, *-опасными). Т.е. лист дерева ищется быстро. А вот позиция в массиве и сам элемент пока никак не ищутся и не хранятся :)

Мапа в данном случае, как мне кажется, слегка избыточна, но может я что не понял...

А, да, соответствие 1:1. Т.е. В может находится только в одном месте.
д0kВозможно слишком сложно , зато масштабируемо , в случае
изменения бизнес хотелок по управлению связями
с меньшей болью придется все переписывать. Спасиб, я подумаю про это, может даже несмотря на 1:1 стоит это сделать.

д0кне обязательно мап подойдет любой контейнер
который устроит вас по скорости поиска.не, у меня вопрос был про то, почему держать информацию об отношениях в отдельном контейнере?
Поясню свою мысль: при любом поиске (А или В) нам надо будет как-то искать один из объектов в контейнере. Если информацию об принадлежности хранить непосредственно в двух объектах А и В, то доступ к инфе получается более быстрым.
MasterZivбольшой - это сколько?10К...100К наверно. Но, тут есть момент, это не один массив, их несколько, все элементы в них уникальные (т.е. один элемент класса А входит только в один массив), в плане отношений B<->A это неважно, это важно только в плане нарезки этих самых массивов.
MasterZivу тебя про владение и время жизни ни слова не сказано, так что можно предположить, что shared ptr вообще не нужен.может и так, но у меня массивы динамические по размеру. Оператором new пользоваться нельзя :) как быть? Во-вторых, нужно держать указатели на объекты этих массивов. Т.е. по науке, должен использоваться механизм, блокирующий возможность удаления объектов класса А, пока на них есть ссылки. И, так как один массив - одна сущность, то и блокирующий возможность удаления самих массивов, пока на один из элементов ссылается объект класса В - это реализовано, В имеет указатель на массив. По идее, это гарантирует, что если я буду использовать опасный указатель внутри В на А, всё будет ОК. Но я могу сменить в объекте класса В указатель на массив и забыть поменять указатель на объект :)
В общем, получается так: нужен механизм, наподобие shared_ptr, но для массива, такой что: если хоть кто-то ссылается на один из элементов массива, массив не может быть удалён.

чтоб проще понимать было, такая аналогия: массивы А - это дискретные карты, а объекты В - это объекты на картах. Обращаясь к объекту В мы должны узнать, на какой он карте и в какой точке. Обращаясь к точке на карте, мы должны узнать, есть ли кто в этой точке. И нельзя удалить карту, если хоть в одной её точке кто-то находится.

д0k1. Отдельный контейнер нужен для экономии ресурсов.Мне пока не понятно. В моём варианте, у меня только 2+ указателя. В твоём варианте это объект класса + 2+ указателя. Ресурсов тратится больше, плюс дополнительный функционал на поиск этого объекта-зависимости.
д0k2. Отдельный контейнер нужен , что бы не не прибивать молотком
определенный тип связи к классу. интуиция мне подсказывает
что типов связи может быть много , если их все включать в классы
то вопрос ресурсов, в том числе человекочасовых на разработку и тестирование
встанет еще жестче.Разработку и тестирование веду я один :)
Теперь по связи. Допустим, типов связи может быть много, всё равно не вижу смысла их выносить в отдельных класс, до тех пор, пока эта связь не обзаведётся своим независимым от А и В функционалом. Далее, большое число типов связей тогда подразумевает:
1. большое число типов связей от А к В
2. большое число типов связей от В к А
в обоих случаях я добавлю в А и В соответственно признак типа связи, а функционал будет в самих этих классах, потому что только они знают, что с ним делать.
д0k3. Мы на форуме где обсуждаются реляционные БД, поэтому
нормализация отношений абсолютно естетственный подход к хранению информации
для людей, которые професионально занимаются базами данных.Ну да, но это слишком общий подход к отношению между данными. А у меня модель довольно простая. Нет, я, конечно, подумаю в эту сторону, но вряд ли что дельное мне в голову придёт(т.е. зачем формализовать отношения в отдельном классе)

д0kЯ же выше сказал , что контейнер содержит только
действительные существующие , иницализированные связи.
Если кто то с кем то не связан определенным типом связь , то
обьекты порознь существуют , но записи описыващей связь
в контейнере нет.А, всё, до меня дошло, у меня в классах указатели уже есть, да, и занимают место.
Ок, ладно, я пока всё равно против отдельной сущности для связи. Допустим, я сделаю дочерние классы А2 и В2 с указателями, которые будут ссылаться на В и А соответственно.

MasterZivshared_arrayесть, но в boost. Хотя, в общем-то, весь проект заводился, чтобы посмотреть, как работает boost::serialization на небольших иерархиях, где используются shared_ptr

MasterZivА ещё можно shared_ptr< verctor <T> >Не, это не совсем хороший вариант. В этом случае мы получаем указатель на вектор и, собственно, гарантию, что сам объект вектора, а не его содержимое, будет жив. В моём случае чуть лучше, у меня указатель держит всю область выделенной памяти. Но это тоже неидеально, потому что если я сделаю shared_ptr на один из элементов, это не удержит элемент в памяти, если я удалю сам массив. boost::shared_array не смотрел, возможно он умеет оперировать ссылками всех своих элементов массива, но тогда скорее всего придётся использовать boost-овский shared_ptr

Что-то я запутался.
MasterZivЕсли в векторе хранить по значению, то оно будет всегда живо.Вектор - это динамический набор элементов. Допустим, мы храним там значения. Потом берём и делаем shared_ptr на один из элементов, а самому вектору делаем несколько erase(), что будет с созданным shared_ptr? Думаю, он будет ссылаться на битую область (boost::shared_array, видимо, в такой ситуации сначала держал бы 2 ссылки на объект, после erase() одну), при этом и вектор и shared_ptr на него - в порядке.
MasterZivНапоминаю, что ранее ты хотел хранить простой массив, в котором всегда всё храниться по значению.я сейчас так и делаю, по той же самой причине: у меня shared_ptr на единый кусок памяти, т.е. не может быть такой ситуации, что shared_ptr на массив живой, а кто-то в массиве дохлый.
Но сейчас я вообще убрал пока shared_ptr-ы, ссылающиеся на элементы массива, потому что нестыковка :) Хорошо бы иметь некое подобие weak_ptr в таком случае...