Сообщение Re[5]: Вопрос по идентификации типа (не RTTI) от 11.04.2019 10:52
Изменено 13.04.2019 9:57 Erop
Re[5]: Вопрос по идентификации типа (не RTTI)
Здравствуйте, niralex, Вы писали:
N>Здравствуйте, Erop, Вы писали:
E>>Здравствуйте, niralex, Вы писали:
N>>>Объекты инстанцируются в разных динамических модулях/процессах, используются разные компиляторы, поэтому эти адреса будут отличаться. Если бы все было в одном модуле то хватило бы стандартного RTTI
E>>IMHO в этом месте надо подробнее рассказать сценарий того, что хочется делать...
N>Попробую описать сценарий... Реализуеся универсальный механизм связывания для делегатов:
N>Если делегат и вызываемая сщность находятся в одном модуле, связывание и передача параметров происходят стандартным образом, но если в разных, параметры проходят процедуру кодирования/декодирования (для согласования форматов представления данных, потокобезопасности и др.) Обработка выполняется кодерами/декодерами, которые реализованы как множество типов, включающих статические методы Encode/Decode.
N>Например:
N>
N>Сценарий такой: функции LocalFunction, GetFromDll и GetRemoteFunction получают информацию о типах кодеров/декодеров для вызываемой сущности из параметров шаблона, из dll или от удаленного узла, а функция Bind проверяет соответствие этих типов. Вот именно для этого и нужно идентифицировать типы и передавать идентификаторы. Поскольку вызовы Bind происходят часто, хочется чтобы идентификация проходила на этапе компиляции (само сравнение, естественно происходит в рантайме).
Если я верно понял, у модулей всё равно есть какая-то подготовка. То есть мы не имеем какой-то API более или менее родной для каждой dll, а включаем в dll наш код для маршелинга. Так?
В любом случае нам нужно обеспечить две вещи.
1) Логическую совместимость вызывающей и вызываемой стороны. Тут должны быть какие-то правила, автоматически или полуавтоматически выводимые. Ну, например, можно ли наследника передавать вместо базы. И т. д.
2) Бинарную совместимость в случае, если (1) есть, но по разные стороны имеются разные языки/среды разработки и т. д.
Казалось бы, бы всегда можем использовать уникальные id всех сущностей, а в RT строить табличку что с чем совместимо с т. з. (1), и, соответственно, что надо использовать для (2)
Правда, если отказаться от идеи, что мы не делаем промежуточный модуль совместимости, а, наоборот, по API dll какой-то тулзой генерить переходную lib, то можно сделать генерилки для N платформ, переходников из каждой в каждую.
При загрузке/финальной сборке будут выбираться правильные версии этих интерфейсов и всё решится само собой во время загрузки приложения...
N>Здравствуйте, Erop, Вы писали:
E>>Здравствуйте, niralex, Вы писали:
N>>>Объекты инстанцируются в разных динамических модулях/процессах, используются разные компиляторы, поэтому эти адреса будут отличаться. Если бы все было в одном модуле то хватило бы стандартного RTTI
E>>IMHO в этом месте надо подробнее рассказать сценарий того, что хочется делать...
N>Попробую описать сценарий... Реализуеся универсальный механизм связывания для делегатов:
N>Если делегат и вызываемая сщность находятся в одном модуле, связывание и передача параметров происходят стандартным образом, но если в разных, параметры проходят процедуру кодирования/декодирования (для согласования форматов представления данных, потокобезопасности и др.) Обработка выполняется кодерами/декодерами, которые реализованы как множество типов, включающих статические методы Encode/Decode.
N>Например:
N>
N>// ---Модуль main---
N>/* Создание делегата с двумя параметрами, для кодирования которых используются void IntCodec::Encode(std::byte *buffer, int Value) и void StringCodec::Encode(std::byte *buffer, string Value) */
N>MyDelegate<IntCodec, StringCodec> d;
N>/* Делегат может быть связан с вызываемыми сущностями, которые предварительно должны быть зарегистрированы */
N>// Создание вызываемых сущностей
N>Callee f1 = LocalFunction<IntCodec, StringCodec>(func); // func - локальная функция с сигнатурой func(int, char)
N>Callee f2 = GetFromDll("libname", index); // index - номер функции, которая зарегистрирвоана в dll
N>Callee f3 = GetRemoteFunction("url", index); // index - номер функции, которая зарегистрирвоана на удаленном узле
N>d.Bind(f1); // связывание с локальной функцией
N>d(1, "direct call == std::funcion()"); // вызов
N>d.Bind(f2); // связывание с функцией из DLL
N>d(2, "Call with encoding/decoding"); // вызов
N>d.Bind(f3); // связывание с удаленной функцией
N>d(3, "Remote call with encoding/decoding"); // вызов
N>// ---Модуль DLL---
N>int index = RegisterFunction<IntCodec, StringCodec>(func); // func - внутренняя функция dll
N>// ---Remote module---
N>int index = RegisterFunction<IntCodec, StringCodec>(func); // func - внутренняя функция dll
N>
N>Сценарий такой: функции LocalFunction, GetFromDll и GetRemoteFunction получают информацию о типах кодеров/декодеров для вызываемой сущности из параметров шаблона, из dll или от удаленного узла, а функция Bind проверяет соответствие этих типов. Вот именно для этого и нужно идентифицировать типы и передавать идентификаторы. Поскольку вызовы Bind происходят часто, хочется чтобы идентификация проходила на этапе компиляции (само сравнение, естественно происходит в рантайме).
Если я верно понял, у модулей всё равно есть какая-то подготовка. То есть мы не имеем какой-то API более или менее родной для каждой dll, а включаем в dll наш код для маршелинга. Так?
В любом случае нам нужно обеспечить две вещи.
1) Логическую совместимость вызывающей и вызываемой стороны. Тут должны быть какие-то правила, автоматически или полуавтоматически выводимые. Ну, например, можно ли наследника передавать вместо базы. И т. д.
2) Бинарную совместимость в случае, если (1) есть, но по разные стороны имеются разные языки/среды разработки и т. д.
Казалось бы, бы всегда можем использовать уникальные id всех сущностей, а в RT строить табличку что с чем совместимо с т. з. (1), и, соответственно, что надо использовать для (2)
Правда, если отказаться от идеи, что мы не делаем промежуточный модуль совместимости, а, наоборот, по API dll какой-то тулзой генерить переходную lib, то можно сделать генерилки для N платформ, переходников из каждой в каждую.
При загрузке/финальной сборке будут выбираться правильные версии этих интерфейсов и всё решится само собой во время загрузки приложения...
Re[5]: Вопрос по идентификации типа (не RTTI)
Здравствуйте, niralex, Вы писали:
N>Сценарий такой: функции LocalFunction, GetFromDll и GetRemoteFunction получают информацию о типах кодеров/декодеров для вызываемой сущности из параметров шаблона, из dll или от удаленного узла, а функция Bind проверяет соответствие этих типов. Вот именно для этого и нужно идентифицировать типы и передавать идентификаторы. Поскольку вызовы Bind происходят часто, хочется чтобы идентификация проходила на этапе компиляции (само сравнение, естественно происходит в рантайме).
Если я верно понял, у модулей всё равно есть какая-то подготовка. То есть мы не имеем какой-то API более или менее родной для каждой dll, а включаем в dll наш код для маршелинга. Так?
В любом случае нам нужно обеспечить две вещи.
1) Логическую совместимость вызывающей и вызываемой стороны. Тут должны быть какие-то правила, автоматически или полуавтоматически выводимые. Ну, например, можно ли наследника передавать вместо базы. И т. д.
2) Бинарную совместимость в случае, если (1) есть, но по разные стороны имеются разные языки/среды разработки и т. д.
Казалось бы, бы всегда можем использовать уникальные id всех сущностей, а в RT строить табличку что с чем совместимо с т. з. (1), и, соответственно, что надо использовать для (2)
Правда, если отказаться от идеи, что мы не делаем промежуточный модуль совместимости, а, наоборот, по API dll какой-то тулзой генерить переходную lib, то можно сделать генерилки для N платформ, переходников из каждой в каждую.
При загрузке/финальной сборке будут выбираться правильные версии этих интерфейсов и всё решится само собой во время загрузки приложения...
N>Сценарий такой: функции LocalFunction, GetFromDll и GetRemoteFunction получают информацию о типах кодеров/декодеров для вызываемой сущности из параметров шаблона, из dll или от удаленного узла, а функция Bind проверяет соответствие этих типов. Вот именно для этого и нужно идентифицировать типы и передавать идентификаторы. Поскольку вызовы Bind происходят часто, хочется чтобы идентификация проходила на этапе компиляции (само сравнение, естественно происходит в рантайме).
Если я верно понял, у модулей всё равно есть какая-то подготовка. То есть мы не имеем какой-то API более или менее родной для каждой dll, а включаем в dll наш код для маршелинга. Так?
В любом случае нам нужно обеспечить две вещи.
1) Логическую совместимость вызывающей и вызываемой стороны. Тут должны быть какие-то правила, автоматически или полуавтоматически выводимые. Ну, например, можно ли наследника передавать вместо базы. И т. д.
2) Бинарную совместимость в случае, если (1) есть, но по разные стороны имеются разные языки/среды разработки и т. д.
Казалось бы, бы всегда можем использовать уникальные id всех сущностей, а в RT строить табличку что с чем совместимо с т. з. (1), и, соответственно, что надо использовать для (2)
Правда, если отказаться от идеи, что мы не делаем промежуточный модуль совместимости, а, наоборот, по API dll какой-то тулзой генерить переходную lib, то можно сделать генерилки для N платформ, переходников из каждой в каждую.
При загрузке/финальной сборке будут выбираться правильные версии этих интерфейсов и всё решится само собой во время загрузки приложения...