проект компилируется в DLL, в проекте есть экспортируемые классы унаследованные от std
линкуется всё с shared CRT
и это приводит к тому что наша DLL почемуто на выходе имеет экспорты методов std классов
проблема в том что если мы линкуем в проект эту длл и другую длл которая тоже слинкована с shared CRT и экспортирует стд унаследованные классы(судя по всему), в итоге получается конфликт потому что некоторые std классы экспортируются сразу из двух либ
как этого избежать? чтобы экспорт унаследованных от стд классов приводил к экпорту только их самих, а не их и их базовых стд классов?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Barbar1an, Вы писали:
B>как этого избежать? чтобы экспорт унаследованных от стд классов приводил к экпорту только их самих, а не их и их базовых стд классов?
Мы еще стопицот лет назад решили эту проблему, и по сей день: никогда не экспортить классы! Только функции!
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
Здравствуйте, Мёртвый Даун, Вы писали:
МД>Здравствуйте, Barbar1an, Вы писали:
B>>как этого избежать? чтобы экспорт унаследованных от стд классов приводил к экпорту только их самих, а не их и их базовых стд классов?
МД>Мы еще стопицот лет назад решили эту проблему, и по сей день: никогда не экспортить классы! Только функции!
Идея здравая. Правильно ли я понимаю, что конструкторы и деструкторы тоже надо явно экспортировать, чтобы в клиентском коде можно было создавать объекты классов (с экспортированными функциями)?
Здравствуйте, uentity, Вы писали:
U>Здравствуйте, Мёртвый Даун, Вы писали:
МД>>Здравствуйте, Barbar1an, Вы писали:
B>>>как этого избежать? чтобы экспорт унаследованных от стд классов приводил к экпорту только их самих, а не их и их базовых стд классов?
МД>>Мы еще стопицот лет назад решили эту проблему, и по сей день: никогда не экспортить классы! Только функции!
U>Идея здравая. Правильно ли я понимаю, что конструкторы и деструкторы тоже надо явно экспортировать, чтобы в клиентском коде можно было создавать объекты классов (с экспортированными функциями)?
зачем? экспортируете функции создания/удаления нужного класса и работаете дальше как обычно
Здравствуйте, DTB, Вы писали:
DTB>Здравствуйте, uentity, Вы писали:
U>>Здравствуйте, Мёртвый Даун, Вы писали:
МД>>>Здравствуйте, Barbar1an, Вы писали:
B>>>>как этого избежать? чтобы экспорт унаследованных от стд классов приводил к экпорту только их самих, а не их и их базовых стд классов?
МД>>>Мы еще стопицот лет назад решили эту проблему, и по сей день: никогда не экспортить классы! Только функции!
U>>Идея здравая. Правильно ли я понимаю, что конструкторы и деструкторы тоже надо явно экспортировать, чтобы в клиентском коде можно было создавать объекты классов (с экспортированными функциями)?
DTB>зачем? экспортируете функции создания/удаления нужного класса и работаете дальше как обычно
у нас так и было, а потом вдруг оказалось что нужно иметь возможность наследоваться от классов из другого проекта
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Barbar1an, Вы писали:
B>у нас так и было, а потом вдруг оказалось что нужно иметь возможность наследоваться от классов из другого проекта
А зачем понадобилось это делать динамически?
Здравствуйте, Barbar1an, Вы писали:
B>проект компилируется в DLL, в проекте есть экспортируемые классы унаследованные от std B>линкуется всё с shared CRT B>и это приводит к тому что наша DLL почемуто на выходе имеет экспорты методов std классов
B>проблема в том что если мы линкуем в проект эту длл и другую длл которая тоже слинкована с shared CRT и экспортирует стд унаследованные классы(судя по всему), в итоге получается конфликт потому что некоторые std классы экспортируются сразу из двух либ
Насколько я помню, в MSVC есть опция линкера, чтобы этого избежать. Когда-то я успешно пользовался ею в такой ситуации.
Приведи, пожалуйста, код ошибки, тогда смогу подсказать что-то конкретнее.
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, Barbar1an, Вы писали:
B>>проект компилируется в DLL, в проекте есть экспортируемые классы унаследованные от std B>>линкуется всё с shared CRT B>>и это приводит к тому что наша DLL почемуто на выходе имеет экспорты методов std классов
B>>проблема в том что если мы линкуем в проект эту длл и другую длл которая тоже слинкована с shared CRT и экспортирует стд унаследованные классы(судя по всему), в итоге получается конфликт потому что некоторые std классы экспортируются сразу из двух либ
AG>Насколько я помню, в MSVC есть опция линкера, чтобы этого избежать. Когда-то я успешно пользовался ею в такой ситуации. AG>Приведи, пожалуйста, код ошибки, тогда смогу подсказать что-то конкретнее.
да проект уже переделал, ошибка там банальная, чтото типа
error LNK2005: бла бла бла already defined in бла бла бла
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, kov_serg, Вы писали:
_>Здравствуйте, Barbar1an, Вы писали:
B>>у нас так и было, а потом вдруг оказалось что нужно иметь возможность наследоваться от классов из другого проекта _>А зачем понадобилось это делать динамически?
в смысле динамически?))) наследуемся мы как обычно наследуются.
наверно вопрос зачем мы экспортировали классы? ну наверно чтобы сборку проекта ускорить же ж,
а еще я не совсем понимаю как кросс-ссылки делать с forward-declaration (класс А использует Б, а Б использует А), если у меня в cpp пусто будет
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, Barbar1an, Вы писали:
B>>проект компилируется в DLL, в проекте есть экспортируемые классы унаследованные от std B>>линкуется всё с shared CRT B>>и это приводит к тому что наша DLL почемуто на выходе имеет экспорты методов std классов
B>>проблема в том что если мы линкуем в проект эту длл и другую длл которая тоже слинкована с shared CRT и экспортирует стд унаследованные классы(судя по всему), в итоге получается конфликт потому что некоторые std классы экспортируются сразу из двух либ
AG>Насколько я помню, в MSVC есть опция линкера, чтобы этого избежать. Когда-то я успешно пользовался ею в такой ситуации. AG>Приведи, пожалуйста, код ошибки, тогда смогу подсказать что-то конкретнее.
это вы наверно путаете с оыбчной проблемой когда у вас линкуется две либы и каждоый совя версия црт, а тут проблема имеет место даже елси версии црт одинаковые, тут не с црт райнтаймом беда а с экспортом црт классов
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Barbar1an, Вы писали:
B>это вы наверно путаете с оыбчной проблемой когда у вас линкуется две либы и каждоый совя версия црт,
Возможно и так, но ИМХО — лекарство разве не одинаковое...
B>а тут проблема имеет место даже елси версии црт одинаковые, тут не с црт райнтаймом беда а с экспортом црт классов
Но там формулировка примерно такая: типа если два одинаковы — добавить флаг если множественное определение...
