Вопрос
У меня есть указатель на QScriptEngine
, который я передаю через перегруженный конструктор класса класса Evaluator
и назначаю его QScriptEngine * engine _
(class Свойство
подклассы Evaluator
и вызывает этот конструктор Evaluator
, передавая ему уже выделенный QScriptEngine
). Конструктор без аргументов создает новый указатель QScriptEngine
(таким образом, подклассы Generic
Evaluator
). В деструкторе, который я проверяю, если engine _
не равен NULL
, удалите указатель, а затем назначьте его NULL
. Должен ли указатель ( engine _
) в производном свойстве
теперь также быть NULL
? Что-то говорит мне, что это не тот случай. Если нет, как вы справляетесь с этой ситуацией? Мне нужно, чтобы QScriptEngine
был одним и тем же экземпляром. Оператор s = QScriptEngine
является закрытым, иначе я бы вообще не использовал указатель. Р>
Я увидел некоторую информацию об общих указателях ( boost :: shared_ptr
и std: tr1 :: shared_ptr
) в другом вопросе SO. Я уже использую boost для библиотеки regex, так что boost не исключен, если это лучший способ справиться с этим. Будем надеяться, что для общего знания C ++ и будущих проектов есть не требующий ускорения способ.
Решение
Вы можете решить эту проблему, предоставив одному из классов (класса A) контроль времени жизни этого указателя вместе с методом getter. Другой класс (класс B) будет всегда вызывать метод получения A всякий раз, когда ему нужен указатель. Таким образом, A всегда будет контролировать указатель. Недостатком является функция получения (она, вероятно, будет встроенной, но это все еще вторая косвенная информация). Кроме того, B придется проверять этот указатель на NULL практически при каждом использовании.
Другой вариант - заключить указатель в нечто вроде boost :: shared_ptr, который решает проблему (при правильном использовании), удерживая базовый указатель и удаляя его только тогда, когда все объекты, которые совместно используют этот указатель, удалены. Вы могли бы написать это самостоятельно, но, поскольку у вас уже есть прирост в игре, я бы просто использовал их реализацию.
Третий вариант заключается в перефакторинге всего этого, чтобы вам не понадобился общий указатель. Лично я никогда не проектировал бы программу на C ++, которая нуждалась бы в общих указателях, просто потому, что это место, где ошибки управления памятью могут легко появиться за эти годы, но это только я.