Альтернативы передаче объектов между модулями

Question

У меня создается впечатление, что по целому ряду причин небезопасно передавать стандартные объекты библиотеки (в частности, шаблонные) между модулями, когда они могут быть скомпилированы с различными версиями стандартной библиотеки или разных компиляторов. Моя цель теперь - найти жизнеспособное решение для этого, особенно в случае общих указателей и строк.

возможных решений, которые приходят на ум, включают в себя:

• C и другие примитивные типы, которые никогда не меняются (не представляется возможным, поскольку требуются более сложные типы)
• Виды из стандартизированной библиотеки, либо:
  • Пользовательский вариант (который требует добавления строки и таких классов, что, честно говоря, звучит ужасно)
  • Некоторая внешняя библиотека, которая уже предоставляет такие вещи (первая мысль - это Boost, но даже без раздувания т включает в себя, он кажется слишком шаблонами тяжело работать)
• Некоторое магическое обстоятельство фактически делает его безопасным (во всех случаях, но shared_ptr)

Реальная проблема, как представляется, такие вещи, как общие указатели, которые сильно зависят от шаблонов.

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

Есть ли решение для этого, которое не связано с внедрением внутреннего подсчета ссылок и пользовательских строк, или это просто цена, которая должна быть заплачена за перекрестную версию/безопасность компилятора/платформы?

Answer 1

Нет решения, помимо разбивки классов на их тривиальные типы элементов и передачи их по отдельности, если вы используете разные компиляторы для компиляции ваших модулей. Если вы используете один и тот же компилятор и только разные его версии, вполне возможно, что модули уже совместимы (если только ABI не изменился, например, в классе и т. Д.). Кроме того, ABI стандартных типов библиотек C++ может быть изменен, в этом случае вы можете обходить его, используя вместо него стороннюю библиотеку, которая обеспечивает те же функции, но гарантирует совместимость с двоичными файлами (например, Qt делает это). Но это не идеальное решение, так как библиотека, используемая вашей основной программой, должна быть более новой, чем версия библиотеки, связанная всеми модулями.Но этого часто бывает достаточно, потому что чаще всего вам нужны только те старые плагины, которые продолжают работать с новой версией вашей программы, а не то, что новые плагины работают со старой версией вашей программы.

Answer 2

Предполагая тот же компилятор используется для обоих модулей, и никто не будет развертывать новую версию только одного модуля ...

Я думаю, что вы можете передавать объекты по модулю (модулями Я имею в виду библиотеки DLL + основные EXE) границы , проблема заключается только в том, что нельзя использовать распределение кучи и статические переменные.

Итак, если вы проходите только структуру, предназначенную для чтения, все должно быть хорошо.

Но как только вы начнете выделять, резервировать и т. Д. И т. Д. Вещи разрываются (разные кучи, без статики).

Можете ошибаться, поэтому, пожалуйста, не пропустите голосов.

Answer 3

Проблема заключается не в передаче объектов между различными модулями, это работает просто отлично. То, что вам нужно обеспечить, - это то, что объекты, созданные модулем X, всегда удаляются модулем X.

Вы можете сделать эту работу, если вы предоставляете функции-обертки для любых операций, требующих выделения/освобождения памяти, чтобы вы имели контроль над тем, какой модуль выполняет эти функции.

Например, это класс заголовок класса, который является безопасной памяти:

class SomeObj { 
private: // private ctor/dtor to prevent outsiders from using them 
    SomeObj() {} 
    virtual ~SomeObj() {} 
public: 
    static SomeObj* create(); 
    void destroy(); 
}; 

А вот реализация:

SomeObj* SomeObj::create() 
{ 
    return new SomeObj(); 
} 

void SomeObj::destroy() 
{ 
    delete this; 
} 

С установкой класса таким образом вы заставляете любой, кто создает или разрушает объект, пройти через create() и destroy(), поэтому модуль, который имеет эти функции, всегда будет управлять памятью для этого класса. Обратите внимание, что create() и destroy() не могут быть встроены.

Для более сложных классов, таких как контейнеры STL, это становится немного сложнее, так как вам нужно будет обернуть больше функций, кроме создания и уничтожения, но это можно сделать.