Здравствуйте, Pzz, Вы писали:

Pzz>Гораздо безопаснее экспортировать из плагина сишный (а не плюсовый) интерфейс. Например, структурку, заполненную указателями на функции. Да, я понимаю, это неудобно, устарело и все такое. Зато это гораздо надежнее, чем то, что делаете вы.

Надежно, это когда такую структуру заполняет компилятор.

А то я, #$%, знаю тут одних таких "заполнятелей".

Дозаполнялись, что получился <вырезано цензурой> Франкенштейн.

Зато типа свой.

Здравствуйте, AlexGin, Вы писали:

AG>Для данного проекта — COM мы НЕ применяем.
AG>Ввиду его большой избыточности.

И правильно. В этой подветке речь идет всего лишь о том, что есть возможность "надежного" (совместимость разных версий приложения, компиляторов, ...) использования интерефейсов с++. Чтобы увидеть это, нужно просто посмотреть на определение COM-интерфейса, вся технология COM здесь несколько сбоку.

A COM interface is nothing more than a named table of function pointers (methods), each of which has documented behavior.

By design, ... a COM interface is binary-compatible with a C++ abstract class.

https://msdn.microsoft.com/en-us/library/ms809982.aspx

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Здравствуйте, AlexGin, Вы писали:

AG>>Предположим такой вариант — загрузил я новый плагин на старом сервере (на старом пирложении). Что дальше?

КД>Плагин запрашивает версию ядра и сравнивает её с минимально поддерживаемой.

КД>Потом начинает запрашивать по IID интерфейсы ядра, через которые он будет взаимодействовать с ним. И если вдруг обнаружит что интерфейс не поддерживается, то значит старым уже является сам плагин

Плагин в данном контексте — это пассивный элемент, загружаемый и запускаемый со стороны головного модуля (приложения).
Он ничего ни у кого не запрашивает. Наоборот — головное приложение запрашивает интерфейс плагина.

AG>>P.S. У нас плагины реализуют некоторые вычислительные задачи, поэтому применение интерфейсов а-ля COM -
AG>>просто напросто усложнит проект, но не решит никаких (имеющихся в контексте наших задач), проблем.

КД>Вообщем тут тебе говорят, что если взялся за гушь делать систему на независимо разрабатываемых модулях — не упрощай и не пытайся изобретать велосипед
Да, велосипеды, мопеды, мотоциклы и даже джипы не нужны, когда мы умеем делать танки!
Это ведь универсальный транспорт — и едет, и стреляет, и пасссажиров защищает.
Зачем делать другой транспорт?

КД>Использование dynamic_cast-ов, исключений, C++ классов через границы модулей до добра не доведет.
Я уже принял решение — делать так, как здесь выше советовал уважаемый товарищ c-smile:
http://rsdn.org/forum/cpp.applied/6932518.1

Автор: c-smile
Дата: 12.10.17

КД>И если хочется простоты, не проще ли тогда скомпилировать все вместе в одном бинарнике?
Бросание в крайности — это наше всё

P.S. Тему считаю закрытой, так как лично я уже определился с решением (см выделенное выше).

Огромное спасибо всем ответившим, и особенно — уважаемому товарищу c-smile!

Ответ которого: http://rsdn.org/forum/cpp.applied/6932518.1

Автор: c-smile
Дата: 12.10.17

Я вижу как наиболее оптимальный, и подходящий для нашего проекта.

Ещё раз напомню, что имеется хороший принцип KISS: https://en.wikipedia.org/wiki/KISS_principle
KISS – keep it simple stupid (делайте вещи проще), который даже важнее, чем применеиние COM любой ценой
https://habrahabr.ru/post/249639

Дальнейшие прения по данной теме возможны, но IMHO не рациональны

Здравствуйте, уважаемый товарищ c-smile!

Я совершенно согласен с твоими доводами, в т.ч. и по dynamic_cast<...>(...)
Считаю идею, которую ты предложил выше: http://rsdn.org/forum/cpp.applied/6932518.1

Автор: c-smile
Дата: 12.10.17

наиболее подходящей для применения в нашем проекте!

Огромное спасибо, за толковый совет!