Блог

Главная - Вопросы по программированию - Экспорт классов в dll переносимым способом, без использования интерфейсов?

Экспорт классов в dll переносимым способом, без использования интерфейсов?

#c #c #dll

#c #c #dll

Вопрос:

У меня вопрос об общих библиотеках / .dll и импорте / экспорте классов. Из того, что я понял после некоторых исследований, два способа сделать это следующие:

  • Просто используйте __declspec(dllexport / dllimport) перед классом и молитесь, чтобы разные версии компилятора искажали имена одинаково, и примите тот факт, что ваш .dll не будет доступна для использования другими компиляторами.
  • Используйте чистые виртуальные классы в dll в качестве интерфейсов. Тогда все классы, которые потребуется экспортировать, унаследуют от них и должны будут реализовывать виртуальные функции. Что за .dll экспортировала бы в этом случае просто «заводские» функции построения / уничтожения, которые создавали бы и освобождали объекты.

    • Это единственные два способа, которые я знаю. Первый вариант не подходит, поскольку он обеспечивает переносимость 0. Второй, хотя и удобный и хороший программный дизайн для .dll, который выполняет определенную цель, начинает раздражать, когда вы понимаете, что вам нужно иметь разные функции конструктора для каждого отдельного конструктора, в качестве параметров можно использовать только типы POD, и вы теряете многие преимущества классов C , такие как перегруженные функции и аргументы функций по умолчанию.

    Для .dll, которая должна предоставлять пользователю библиотеку, коллекцию классов, например, даже второй способ становится действительно неудобным. Итак, мне интересно, каково здесь решение? Просто скомпилируйте другой .dll с первым способом для каждого основного компилятора? Как работает версия больших библиотек с разделяемыми библиотеками? Например, wxWidgets действительно предлагает .версия dll тоже. Как они добиваются нормального использования классов конечным пользователем .dll избегает интерфейсного решения?

    Комментарии:

    1. В C нет стандартного ABI. Если вы хотите настоящую переносимость, вам придется придерживаться C.

    2. Я понимаю это и знаю, что единственным по-настоящему переносимым языком является C, но мой вопрос все еще остается в силе. Как таким большим переносимым библиотекам, как wxWidgets, удается иметь динамические / совместно используемые библиотеки?

    3. Я полагаю, что wxWidgets распространяется в исходном виде и позволяет вам создавать его самостоятельно для вашего компилятора.

    4. Да, это правда, мой пример совсем не был хорошим. Допустим, вы хотите создать API, сложную коллекцию классов и функций, и хотите предоставить их через . dll для пользователя переносимым способом. Нет другого способа, кроме использования интерфейсов по умолчанию?

    5. Вам придется выпускать по одной DLL для каждой версии компилятора. Если вы знаете, что ваши пользователи находятся на VC , то вы можете придерживаться этого.

    Ответ №1:

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

    Кстати, Visual Studio 2012 Release Candidate все еще можно загрузить с:http://msdn.microsoft.com/en-us/vstudio/bb984878.aspx. Может быть, вам стоит попробовать это?