Comments 9
Без обид, plugin.cpp сильно попахивает. Тут и delete this, и утечка в последнем методе. RAII уже давно придумали)
Тут и delete this
Здесь просто идёт переназначение деструктора на другой метод free (он автоматически вызывается с помощью умного указателя при удалении объекта). Где конкретно вы увидели утечку? Посмотрите исходники полностью там это есть.
Я не говорю, что здесь 100% утечка, я говорю, что код попахивает. Вполне возможно, конкретно в этом вашем (предельно упрощённом) варианте утечек нет.
Просто вы пытаетесь прикрутить свой плагин на Паскале к чужому коду на плюсах. И делаете это «общественно-опасным образом». После delete this объект вообще трогать нельзя, любое самое невинное обращение может окончится access violation. В том числе попытка вызвать деструктор (повторно!), что вообще на автомате может случиться. С другой стороны, если free не вызвать, будет утечка. Вы действительно так уверенны, что пользователи вашего плагина — программисты С++ — везде вот так строго соблюдают этот, мягко скажем, нестандартный для плюсов протокол?
Как минимум, я бы перенёс содержимое Plugin::free внутрь деструктора, оставив там только delete this, если уж без него никак.
Просто вы пытаетесь прикрутить свой плагин на Паскале к чужому коду на плюсах. И делаете это «общественно-опасным образом». После delete this объект вообще трогать нельзя, любое самое невинное обращение может окончится access violation. В том числе попытка вызвать деструктор (повторно!), что вообще на автомате может случиться. С другой стороны, если free не вызвать, будет утечка. Вы действительно так уверенны, что пользователи вашего плагина — программисты С++ — везде вот так строго соблюдают этот, мягко скажем, нестандартный для плюсов протокол?
Как минимум, я бы перенёс содержимое Plugin::free внутрь деструктора, оставив там только delete this, если уж без него никак.
Вместо деструктора ВСЕГДА в данной плагинной системе должен вызываться метод free и только он. Это всё делается в загрузчике плагинов автоматом при удалении. Зачем вы думаете в COM технологии используется метод Release. Это система основанная на интерфейсах. А если плагин например написан на java (кажется в ней есть нормальная поддержка интерфейсов в том числе и без использования QueryInterface, AddRef с использованием jni можно прикрутить к с++) откуда программа на с++ будет знать где в памяти расположен java деструктор, для этого и нужен метод free. Он его и будет вызывать…
В статье нет никаких упоминаний о «данной плагинной системе» (какой, кстати)? Это раз.
И, в любом случае это не повод писать говнокод и пропихивать его в туториалы для начинающих — это два. Надо «в данной плагинной системе» использовать free — используйте. Но и на правила языка класть болт не надо. Плюсы это вам не паскаль какой-нибудь или там джава, здесь можно отстрелить себе не только ногу, но и голову.
И, в любом случае это не повод писать говнокод и пропихивать его в туториалы для начинающих — это два. Надо «в данной плагинной системе» использовать free — используйте. Но и на правила языка класть болт не надо. Плюсы это вам не паскаль какой-нибудь или там джава, здесь можно отстрелить себе не только ногу, но и голову.
Ну так то я галку туториал не ставил. например вот описание более сложной системы плагинов там же и про delete this и про выстрел в ногу и почему будет осечка. вот описание com с ссылками на книжки. delete this используется в книге «Основы COM» Дейл Роджерсон. Думаю в книгах по ссылке то же самое… Вот вам скриншот из книги: 
И да, я понимаю ваши чувства: неправильное использование delete this и все такое, но это реально используется в com (ActiveX DirectX) и не только, смиритесь с этим.
Не трогайте вы COM, ActiveX и прочие фекалии мамонта. Это не пример хорошей архитектуры.
По сути: моя претензия была не к delete this, а к его оформлению. В методе free должен быть только delete this (плюс страшный комент на тему «сюда больше ничего не писать»), вся остальная логика — в деструкторе (который будет этим delete вызвано).
Во-первых, потому что человек, пишущий плагин на паскале/java/..., может быть не силён в тонкостях плюсов, и по-ошибке написать что-нибудь после delete this. Причем в дебаге оно может и работать, а вот на релизе — трудноуловимо падать.
Во-вторых, потому что кто-то на другой стороне вполне может юзать ваш плагин так, как это принято в С++, а не в Си:
По сути: моя претензия была не к delete this, а к его оформлению. В методе free должен быть только delete this (плюс страшный комент на тему «сюда больше ничего не писать»), вся остальная логика — в деструкторе (который будет этим delete вызвано).
Во-первых, потому что человек, пишущий плагин на паскале/java/..., может быть не силён в тонкостях плюсов, и по-ошибке написать что-нибудь после delete this. Причем в дебаге оно может и работать, а вот на релизе — трудноуловимо падать.
Во-вторых, потому что кто-то на другой стороне вполне может юзать ваш плагин так, как это принято в С++, а не в Си:
int main() {
auto plugin = *getNewPlugin();
// do something ...
} /* plugin будет убит автоматом, без всяких вызовов plugin.free() */
По сути: моя претензия была не к delete this, а к его оформлению. В методе free должен быть только delete this (плюс страшный комент на тему «сюда больше ничего не писать»), вся остальная логика — в деструкторе (который будет этим delete вызвано).
Ну вот с этого и надо было сразу начинать с конкретного указания что к чему. Тут я с вами согласен, спасибо, исправлю. Коммент добавлю.
Насчет использования в другом приложении это вы конечно загнули. Если только это не приложение совместимое с этими плагинами (какой-нибудь форк). Но конечно такое тоже возможно и лучше тоже коммент добавить. Спасибо.
Sign up to leave a comment.
Как быть если компилятор не поддерживает интерфейсы с нулевым смещением VMT