К вопросу об экспортировании классов в DLL

yolki

насколько это разумно/возможно делать напрямую типа



#if defined( BUILD_DLL )

    #define IMPORT_EXPORT __declspec(dllexport)

#else

    #define IMPORT_EXPORT __declspec(dllimport)

#endif

class IMPORT_EXPORT MyClass {

    ...

};

?
насколько это переживёт разные версии студии? например 2005 vs 2010 ?
какие есть альтернативы?

vik1538

Так и делают. Разумных альтернатив нет. Во всех студиях одинаково.

yolki

сасибо.
хотелось бы подтверждения например такого: DLL собрана 2005-й студией, а теперь нормально используется с проектом, собираемым в 2010-й.
не поменялось ли там чего?

Whoman-in-white

насколько это разумно/возможно делать напрямую типа
code:
#if defined( BUILD_DLL )
    #define IMPORT_EXPORT __declspec(dllexport)
#else
    #define IMPORT_EXPORT __declspec(dllimport)
#endif
class IMPORT_EXPORT MyClass {
    ...
};

Самая переносимая вещь - это объявить абстрактный класс и функцию, которая его будет создавать (через def-файл таблица виртуальных функций везде одинаково устроена вроде как.

Serab

таблица виртуальных функций везде одинаково устроена вроде как.

да, это так, потому что COM

vik1538

Лично собирал одно и тоже 2003 2005 2008 и 2012 студией, 2010 не собирал, но знаю, что там также.

vik1538

А ты походу не об этом)
Заморочек касательно этой конструкции нет.
Но ваще принято собирать все одной студией, заморочки есть, например в каждой студии свой рантайм, lib файл взависимости от настроек не всегда совместимы ну и т.д.

Whoman-in-white

Так dll вроде и пишутся обычно с тем расчетом, что бы можно было совместно использовать dll, скомпилированные разными компиляторами, не?

Serab

это надо еще написать с этим расчетом, в частности, это должен быть чисто C-интерфейс, позаботиться об интерфейсе выделения/освобождения памяти и т.д.
А если спокойно стрингами перебрасываться, то уже лучше бы одну версию стандартной библиотеки...

yolki

да, именно об этом.
как срастутся разные runtime, разные аллокаторы.
а если у меня одна dll - отладочная, а другая - релизная?

Serab

лучше не рисковать

yolki

ясно. останемся тогда на чистом С интерфейсе.

Maurog

подобный вопрос обсуждали здесь:

Whoman-in-white

это должен быть чисто C-интерфейс,

а чем абстрактные классы плохи?

Serab

это тоже ок

Я косячно выразился, имелось в виду, что не надо обмениваться объектами стандартной библиотеки (и ссылками на них)

Whoman-in-white

Разные рантайм (как мне кажется) нормально срастутся, если перебрасываться только PODструктурами и указателями на абтрактные классы. Распределение памяти никак не срастется, память надо же удалять в той же dll, где выделил.

Оставить комментарий