Правильный способ выставить сложный недолговечный объект

Question

Я разрабатываю дарвиновский симулятор эволюции. По соображениям производительности он написан на C ++. Сим представлен экземпляром World. Животные представлены экземплярами Animal, довольно сложного объекта. Мир имеет два важных метода:

animal_at(int i) 

и

evolve(int n). 

animal_at возвращает ненулевой необработанный указатель на экземпляр Animal, представляющий i-го животного.
evolve продвигает симуляцию, возможно , аннулируя любой указатель, возвращаемый animal_at . Я хочу сделать сима и животных легко доступными снаружи. У меня есть привязки к Python, но я рассматриваю изучение CORBA или Ice для реализации более общего интерфейса. Проблема в том, как мне выставить животных. У меня есть две идеи, ни одна из которых не является удовлетворительной: 1) Немного переписать код, чтобы использовать shared_ptr вместо необработанного ptr и использовать промежуточное ПО, которое понимает семантику shared_ptr. 2) Создайте «глубокий ленивый прокси», который имеет ту же структуру, что и Animal. Его участники будут рекурсивными доверенными лицами членов Animal. animal_at будет фактически вызван в последний момент перед обращением к фактическим данным - указатель будет использован и немедленно отброшен. Это реализовало бы семантику "последнего момента".

Мне не нравится 1), потому что мне пришлось бы вводить состояние объекта "зомби", которое для меня выглядит не элегантным. Мне не нравится 2), потому что единственная цель прокси-сервера - реализовать семантику «последнего момента».

Я ищу автоматический ненавязчивый способ (с использованием генерации кода) для достижения этой цели, потому что я не хочу скрывать значение исходного кода. Есть ли «официальное» название для того, что я называю «семантикой последнего момента»?

Answer 1

Существует возможность использования boost :: weak_ptr. Вы можете передать их, они должны использовать lock (), чтобы получить базовый shared_ptr, чтобы они могли видеть, больше не существует ли объект.

Время жизни объекта определяется только теми местами, где хранится shared_ptr. Поэтому в течение всего времени существования объекта должен быть хотя бы один из них, и он вам нужен, прежде чем вы сможете создать слабый_птр.

Answer 2

Я не понимаю, почему вы хотите экспортировать указатель вместо экспорта интерфейса, который кажется именно той семантикой «последнего момента», которая вам нужна. Ваш animal_at может вернуть объект id , а не указатель, а интерфейс предоставит весь необходимый доступ к объекту, например dosomething(id, params). Интерфейс также может включать блокировку / разблокировку для обеспечения атомарного доступа.

Answer 3

Если ваша animal_at функция возвращает указатель, который может быть признан недействительным в любой момент в будущем, вы можете попытаться заставить его вернуть умный указатель (я бы предложил здесь shared_ptr над weak_ptr, но вы может обойтись со слабым указателем, если вы осторожны с реализацией). Однако вместо того, чтобы указывать прямо на объект Animal, пусть он указывает на объект boost::optional<Animal>. Таким образом, когда вы отменяете указатель, вы можете установить флаг invalid на указатель, и любой пользователь вновь аннулированного объекта сможет проверить, нужно ли ему получить новый указатель.

Answer 4

Во-первых, вы могли бы рассматривать xml-rpc вместо CORBA в качестве промежуточного программного обеспечения (более стандартное использование в настоящее время).

Во-вторых, внешние пользователи работают с маршаллированными данными.Они посылают маршалловую ссылку через промежуточное ПО и ожидают маршаллированной информации на основе их запроса и ссылки, поэтому я не вижу, как это работает вместе с семантикой и указателями «последнего момента».Вы либо сохраняете всех своих временных животных, чтобы их могли запрашивать внешние пользователи, либо вам, вероятно, придется отправить множество исключений для не найденных животных.(или вы позволите им запросить «последнее» животное)