Привет.

Я тут на досуге занялся
размещением экзекмляров класса(ов) в разделяемой памяти Unix.

Исходя из этого вопросы:

1. Есть класс, в параметрах конструктору передаются
значения из которых можно посчитать объем необходимой для
выделения памяти для экземпляра класса.
У него переопределены операторы new & delete.
Как из new добраться до параметров с которыми
вызывается конструктор.
И возможно ли это в приципе?


Вопрос 2.
Как запретить создане экзепляра класса в стеке, чтобы компиллер(GCC) ругался сразу при компиляции либо линковке.


ps Ссылки по теме приветстуются.

blindedКруто, ты еще класс с виртуальными функциями туда запхай

Тут бы разобраться с выделением памяти,
а потом и к виртуальным методам переходить можно.

Из всей информации которую мне удалось найти по данному вопросу
все сходится на том, что если классы находящиеся в разделяемой памяти
инициализированны до fork то с виртуальными функциями проблем быть не должно.
При этом разделяемая память должна подключаться по одинаковому
адресу для всех процессов.

Или Вам извесны другие проблемы в этой области?


Меня пока интересует принцип применения данного подхода и
какими уже извесными граблями можно получить по лбу :)

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


С этим мне все ясно, спасибо.
С виртуальными функциями действительно будут некоторые пробемы.

blinded
Тепер, что касается выделения памяти. со вторым вопросом надеюсь все ясно, без хаков понять где расположен обект на хипе, стэке и тп понять нельзя.
что касается вопроса 1 то непонятно зачем вам это - добираться до параметров конструктора. вам же передадут в new кол-во байтов. а ежели требуется внутри конструктора выделить память так и обращайтесь в своему распределителю. Ежеди требуется STL контейнеры разместить - ну так переписывайтк allocator

Если смотреть на сами классы то они будут выглядеть приблизительно так


Так как количество элементов массива будет извесно только
на этапе выполнения и их будет достаточно много
( несколько сотен тысяч), то хочется разделяемую память выделить один раз и сразу под все одним оператором new.

Похоже ничего из этого не выйдет.

Идея была в том чтобы в хипе не хранить кучу указателей на разделяемую память(сэкономить).

blindedможно проднлать следю трюк - спрятать конструктор в private, на всеющее обозрение вытащить производящую фенкцию (статчкский метод класса, все равно у нас классы конкретные) А эту статическую функцию реализовать след. образом
1) отдельно выделение памяти в shared memory рамер обекта + размер массива
2) вызов оператора new с явным размещением по указанному адресу
Этим решается и первая и вторая проблемы
1)объект кроме как в разделяемой памяти не создашь
2)ну и размещаем его одним куском
Ps ежели полкчится поделись... А то тут жаба на грудь упала и продыха нет
PPS Колобок, прости, видишь пригодилось...

Огромное СПАСИБО за совет.

Что из этого вышло(см аттач):

1. Конструктор спрятать не удалось.

2. Объекты массива размещаются правильно(см. shm.dmp) и там где нужно.

3. Для обьектов массива не вызываются конструкторы и деструкторы
по умолчанию,
хотя сами обьекты якобы живые, обращение к медодам не приводит к
падению. Им нужно тоже писать оператор new или
new [] и инициализировать явно.
Как зделать автоматический вызов я пока не знаю.

4. Необходим контроль за соответствием параметров статической функции
аллокатора и коструктора, я его попытался организовать на скорую руку.

Разделение доступа между процессами там пока нет.

з.ы. Конструктиваная критика приветствуется.

blindedКруто, ты еще класс с виртуальными функциями туда запхай

Кстате оцените идею.

Если виртуальные классы , находящиеся в разделяемой памяти поместить в разделяемую
библиотеку которую загружать во все процессы по одниковым адресам.
И Подкочение процесса к памяти тоже делать через библиотеку.

По идее таблицы виртуальных методов будут находиться во всех процессах
по одним адресам.

Будет ли библиотека будет разруливать правильность адресов?
Насклько технологичным будет такой подход?
На какие подводные камни можно при этом налететь?