Всем привет!

'identifier' : class 'type' needs to have dll-interface to be used by clients of class 'type2'

Ругается на __declspec(dllexport) класс, где в разделе protected: объявлен вектор std::vector<another_class> m_field;. VS 2005 Beta 2. Что это такое и как с этим бороться? Проблема в том, что я не вижу связи между примером в MSDN и моим кодом...

А>

А>'identifier' : class 'type' needs to have dll-interface to be used by clients of class 'type2'

А>Ругается на __declspec(dllexport) класс, где в разделе protected: объявлен вектор std::vector<another_class> m_field;. VS 2005 Beta 2. Что это такое и как с этим бороться? Проблема в том, что я не вижу связи между примером в MSDN и моим кодом...
А>

Допустим, твой_класс, вместе с another_class живут в A.dll и ты захотел поюзать это хозяйство из B.dll.

Допустим ты позвал твой_класс::твой_метод(). Здесь всё нормально — весь твой_класс объявлен как __declspec(dllexport), и из dll будет проэкспорчена ф-ия твой_класс::твой_метод (ну, не с такими красивыми именами).

А теперь, допустим, твой_класс::твой_метод() оказался inline и компилятор решил его проинлайнить, а внутри себя твой_метод полез в another_class::another_method(). Таким образом, внутри B.dll надо сгенерить вызов another_class::another_method().
А вот another_class уже, скорее всего, не __declspec(dllexport) (раз компилятор ругается), поэтому вызвать его из B.dll не получится (Unresolved external). Об этом тебя заранее и предупреждают.

По-моему подобный эфект может вызвать и само наличие std::vector<something>, который тоже является классом, который тоже не объявлен __declspec(dllexport).

А>А теперь, допустим, твой_класс::твой_метод() оказался inline и компилятор решил его проинлайнить, а внутри себя твой_метод полез в another_class::another_method(). Таким образом, внутри B.dll надо сгенерить вызов another_class::another_method().
А>А вот another_class уже, скорее всего, не __declspec(dllexport) (раз компилятор ругается), поэтому вызвать его из B.dll не получится (Unresolved external). Об этом тебя заранее и предупреждают.

А>По-моему подобный эфект может вызвать и само наличие std::vector<something>, который тоже является классом, который тоже не объявлен __declspec(dllexport).

Спасибо, всё ясно... Ну да, это именно на вектор и ругается. Я убирал всё, оставляя только вектор, конструктор. и деструктор. А что же делать? Мне очень нужна dll с классом. А классу нужен вектор.. собственно, без вектора он ни на что не годен. Может, запретить инлайнить мои методы? По идее должно помочь...

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

А>>А теперь, допустим, твой_класс::твой_метод() оказался inline и компилятор решил его проинлайнить, а внутри себя твой_метод полез в another_class::another_method(). Таким образом, внутри B.dll надо сгенерить вызов another_class::another_method().
А>>А вот another_class уже, скорее всего, не __declspec(dllexport) (раз компилятор ругается), поэтому вызвать его из B.dll не получится (Unresolved external). Об этом тебя заранее и предупреждают.

А>>По-моему подобный эфект может вызвать и само наличие std::vector<something>, который тоже является классом, который тоже не объявлен __declspec(dllexport).

А>Спасибо, всё ясно... Ну да, это именно на вектор и ругается. Я убирал всё, оставляя только вектор, конструктор. и деструктор. А что же делать? Мне очень нужна dll с классом. А классу нужен вектор.. собственно, без вектора он ни на что не годен. Может, запретить инлайнить мои методы? По идее должно помочь...

Забить.
Вектор — шаблонный класс, полностью определённый в заголовке, и ситуации, когда его методы не доступны возникнуть вроде-бы не может.
Единственное, надо заботиться о том, чтобы обе dll видели один и тот же вектор (одни и те же заголовки). Обычно, оно само собой получается, но может случиться, что, скажем, скомпиляли A.dll, проапгрейдили компилятор (что могло поменять заголовки), скомпиляли B.dll.
Тогда может случиться всё, что угодно

> Спасибо, всё ясно... Ну да, это именно на вектор и ругается. Я убирал всё,
> оставляя только вектор, конструктор. и деструктор. А что же делать? Мне
> очень нужна dll с классом. А классу нужен вектор.. собственно, без вектора
> он ни на что не годен. Может, запретить инлайнить мои методы? По идее
> должно помочь...

Просто запрети ворнинг.

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


>> Спасибо, всё ясно... Ну да, это именно на вектор и ругается. Я убирал всё,
>> оставляя только вектор, конструктор. и деструктор. А что же делать? Мне
>> очень нужна dll с классом. А классу нужен вектор.. собственно, без вектора
>> он ни на что не годен. Может, запретить инлайнить мои методы? По идее
>> должно помочь...

S>Просто запрети ворнинг.

Я так понял, что если я просто запрещу ворнинг, а он гденибудь проинлайнит мой метод, будет unresolved external непонятно откуда, а это не дело...

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

А>Всем привет!

А>

А>'identifier' : class 'type' needs to have dll-interface to be used by clients of class 'type2'

А>Ругается на __declspec(dllexport) класс, где в разделе protected: объявлен вектор std::vector<another_class> m_field;. VS 2005 Beta 2. Что это такое и как с этим бороться? Проблема в том, что я не вижу связи между примером в MSDN и моим кодом...
А>

Скрой вектор. Если тебе не надо, чтобы пользователь твоей длл смог создать класс, унаследованный от твоего, и который мог бы достучаться к вектору, то лучшим решением тут будет пимпл.

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

BF>Скрой вектор. Если тебе не надо, чтобы пользователь твоей длл смог создать класс, унаследованный от твоего, и который мог бы достучаться к вектору, то лучшим решением тут будет пимпл.

К несчастью, надо. У меня есть несколько представлений данных, с которыми оперирует моя программа. Эта dll будет содержать базовые классы, описывающие "представление данных". Далее будет по одной dll на каждое представление (xml, bin, db, ...), и фабрика, настраиваемая форматом и создающая нужные конкретные классы. Ну а там уже будет моя прога, которая эту фабрику будет настраивать и лопатить данные.

Специфика задачи делает этот вектор очень нужным в базовом классе. И конечно же, его очень хочется видеть в наследниках — реализациях, которые отличаются только меанизмами доступа к данным... следовательно, он protected...

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

А>Единственное, надо заботиться о том, чтобы обе dll видели один и тот же вектор (одни и те же заголовки). Обычно, оно само собой получается, но может случиться, что, скажем, скомпиляли A.dll, проапгрейдили компилятор (что могло поменять заголовки), скомпиляли B.dll.
А>Тогда может случиться всё, что угодно

Такого случиться вроде не должно, потому как на данный момент всё перекомпиляется вместе разом. Но как потом оно будет —