Подскажите пожалуйста могут ли быть какие либо проблеммы при использовании в одном проекте dlls собранных разными версиями visual studio
Приложение должно собираться vs2008 часть dll используемых приложением должно собираться в vs6 (при желании можно собрать в vs2003), одна в 2005
Собрать все в vs2005/2008 возможности нет так как в проекте используються lib и код расчитанный на vs6
dll собранные разными компилятора в одном проекте
| От: | Кодт | |
| Дата: | 05.03.09 14:59 | |
| Оценка: | 21 (4) | |
| #Имя: | FAQ.cpp.dll.problems | |
Здравствуйте, sergey2b, Вы писали:
S>Подскажите пожалуйста могут ли быть какие либо проблеммы при использовании в одном проекте dlls собранных разными версиями visual studio
Проблем может быть дофигища самых разнообразных, поэтому лучше договориться — как избегать проблем.
Язык Си. #023. Компиляция программы.
Недекорированные имена.
Разные компиляторы декорируют по-разному, поэтому экспортировать/импортировать нужно, либо объявляя extern «C», либо вообще .def-файлами.
Естественно, что перегрузка здесь обламывается.
Менеджеры памяти (в составе CRT).
Не надеяться на то, что они общие для всех — даже компилируя с опциями «(Debug) (Multithreaded) DLL». Для разных версий компилятора рантаймы разные.
Поэтому никаких выделений памяти в одном месте и утилизации в другом — только всё своими силами.
Соответственно, библиотека, отдающая наружу свежесозданный объект (да хоть строку), должна использовать одну из техник:
— экспортировать функции утилизации
— протащить функцию утилизации через интерфейс объекта (например, COM — IUnknown::Release)
— использовать менеджер памяти ОС (например, COM — SysAllocString, CoTaskMemAlloc и т.д.)
Использовать стандартные конвенции — cdecl и stdcall. Всякие fastcall могут реализовываться по-разному даже у одного компилятора в зависимости от ключа оптимизации.
Если сишный API слишком узок, использовать COM. Необязательно, что это будет полноценный inproc server, можно и легковесные (без регистрации коклассов). Все виндоузные компиляторы совместимы с COM.
Более общий С++ный ООП не экспортировать — могут быть разные лэяуты, разные конвенции thiscall, дубликаты статических переменных.
Не кидать исключения за пределы своего модуля. Даже сквозь колбэк-функцию
typedef void F(); typedef void G(F); void f() < throw something; > void h(G g) // где G берётся из другого модуля < try < g(f); >catch(something) < >>
Перекуём баги на фичи!
Re[2]: dll собранные разными компилятора в одном проекте
| От: | byleas |
| Дата: | 05.03.09 17:22 |
| Оценка: |
Здравствуйте, Кодт, Вы писали:
Уроки Java для начинающих #3 | Компиляция программы
S>>собранных разными версиями visual studio
К>Разные компиляторы декорируют по-разному
А разве разные версии одного компилятора декорируют по-разному? undname, во всяком случае, понимает все имена, кроме декорированых с rvalue references, но их и сама студия 2010 не понимает
K> Не кидать исключения за пределы своего модуля
Почему?
Re[2]: dll собранные разными компилятора в одном проекте
| От: | sergey2b |
| Дата: | 05.03.09 17:44 |
| Оценка: |
Здравствуйте, Кодт, Вы писали:
К>Проблем может быть дофигища самых разнообразных, поэтому лучше договориться — как избегать проблем.
Спасибо за ваш ответ.
Скажите пожалуйста если есть выбор что лучше использовать vs6 или vs2003 для создания dll на C/C++
Re[3]: dll собранные разными компилятора в одном проекте
| От: | Кодт |
| Дата: | 06.03.09 09:08 |
| Оценка: |
Здравствуйте, sergey2b, Вы писали:
S>Скажите пожалуйста если есть выбор что лучше использовать vs6 или vs2003 для создания dll на C/C++
VC6 — довольно древний компилятор. Он и язык менее полно поддерживает, и ошибки содержит.
Но если ты не упираешься в эти ограничения — пожалуйста, пользуйся.
Хотя я бы предпочёл что-нибудь более новое.
Перекуём баги на фичи!
Re[3]: dll собранные разными компилятора в одном проекте
| От: | Кодт |
| Дата: | 06.03.09 10:08 |
| Оценка: |
Здравствуйте, byleas, Вы писали:
K>> Не кидать исключения за пределы своего модуля
B>Почему?
Потому что «на той стороне» его должны обработать (как минимум, размотать стек).
Во-первых, исключение могут поймать. И это даёт почву для нарушения ODR — например, ты кидаешь std::logic_error, объявленный в твоей версии STL — а там ловят std::logic_error, объявленный в другой версии STL. Разные лэяуты, и привет.
Во-вторых, если тот код не собирается обрабатывать исключения (трактует твою функцию как не бросающую; а для extern»C»-функций есть такая опция компилятора), — это ситуация UB или terminate, сейчас затруднюсь сказать.
Перекуём баги на фичи!
Re[3]: dll собранные разными компилятора в одном проекте
| От: | Аноним |
| Дата: | 06.03.09 13:26 |
| Оценка: |
Здравствуйте, sergey2b, Вы писали:
S>Здравствуйте, Кодт, Вы писали:
S>Скажите пожалуйста если есть выбор что лучше использовать vs6 или vs2003 для создания dll на C/C++
я бы сказал, что лучше использовать vs2003 в любом случае, а не только «для создания dll»
Re[4]: dll собранные разными компилятора в одном проекте
| От: | sergey2b |
| Дата: | 06.03.09 17:28 |
| Оценка: |
Здравствуйте, Аноним, Вы писали:
S>>Скажите пожалуйста если есть выбор что лучше использовать vs6 или vs2003 для создания dll на C/C++
А>я бы сказал, что лучше использовать vs2003 в любом случае, а не только «для создания dll»
Чем он лучше в случаи C и pure C++ ?
Re: dll собранные разными компилятора в одном проекте
| От: | MasterZiv | |
| Дата: | 06.03.09 19:15 | |
| Оценка: | 3 (1) -2 | |
sergey2b пишет:
> Подскажите пожалуйста могут ли быть какие либо проблеммы при
> использовании в одном проекте dlls собранных разными версиями visual studio
Тут все проблемы делятся на два случая:
— ваши приложения используют C/С++ rumtime library
— ваши приложения НЕ используют C/С++ rumtime library
Во втором случае всё гораздо легче. Собственно, во втором случае
вообще никаких проблем быть не должно.
В первом — все модули (*.exe и *.dll) вашего приложения должны
использовать РОВНО ОДНУ И ТУ ЖЕ библиотеку C runtime library (CRTL).
CRTL от vc6 и vc2003/2005/8 несовместимы бинарно, на сколько я знаю.
Так что либо одно, либо другое (правда и тут есть нюансы, это запрещение
не фатальное, при желании и условиях оно обходится).
> Приложение должно собираться vs2008 часть dll используемых приложением
> должно собираться в vs6 (при желании можно собрать в vs2003), одна в 2005
Ну, тут ещё ничего не ясно, надо смотреть.
Posted via RSDN NNTP Server 2.1 beta
Re: dll собранные разными компилятора в одном проекте
| От: | MasterZiv | |
| Дата: | 06.03.09 19:17 | |
| Оценка: | -1 | |
Кодт пишет:
>
> Недекорированные имена.
При чём тут декорированные или недекорированные имена ?
> Если сишный API слишком узок, использовать COM. Необязательно, что это
Ужас. Ну и советы.
Posted via RSDN NNTP Server 2.1 beta
Re[3]: dll собранные разными компилятора в одном проекте
| От: | MasterZiv |
| Дата: | 06.03.09 19:22 |
| Оценка: |
sergey2b пишет:
> Спасибо за ваш ответ.
> Скажите пожалуйста если есть выбор что лучше использовать vs6 или vs2003
> для создания dll на C/C++
Что значит «что лучше» ? It epends, как говорится.
Исходя из того, что вы используете, и как, всё это будет очень
сильно разнится.
В топике вашем нет какой-то информации, которая бы позволяла
дать какие-то рекомендации, кроме той, что «лучше быть богатым
и здоровым, чем бедным и больным», т.е. что лучше писать на
vc2005/vc2008, а не на древнем уже vc6.
Posted via RSDN NNTP Server 2.1 beta
Re[2]: dll собранные разными компилятора в одном проекте
| От: | sergey2b |
| Дата: | 06.03.09 21:25 |
| Оценка: |
Здравствуйте, MasterZiv, Вы писали:
Спасибо за ваш ответ.
MZ>— ваши приложения НЕ используют C/С++ rumtime library
как приложение или dll может не использовать rtl ?
MZ>В первом — все модули (*.exe и *.dll) вашего приложения должны
MZ>использовать РОВНО ОДНУ И ТУ ЖЕ библиотеку C runtime library (CRTL).
MZ>CRTL от vc6 и vc2003/2005/8 несовместимы бинарно, на сколько я знаю.
MZ>Так что либо одно, либо другое (правда и тут есть нюансы, это запрещение
MZ>не фатальное, при желании и условиях оно обходится).
В моем случаи вприложение на pure C++, все dll написанны на чистом C, все исключения обрабатываються внутри dlls, в функции dll передаються простые параметры типо DWORD, char* возвращаеться DWORD.
Как в таком случаи различия версий rtl в dll могут повлиять?
>> Приложение должно собираться vs2008 часть dll используемых приложением
>> должно собираться в vs6 (при желании можно собрать в vs2003), одна в 2005
MZ>Ну, тут ещё ничего не ясно, надо смотреть.
В данный момент вся система написанна и компилица на VC6
планируеться сделать две версии системы x86 и x64
две dll из системы собираються с использованием чужих sdk lib и include которых расичтанны на VC6 (но я могу откомпилировать их в vc2003 с минимальными изменениями, в vc2005 собрать их неполучаеться)
Я планирую две dll испольузющие чужие sdk собирать VC6 или VC2003 (вопрос чем лучше VC2003 если код чистый Си возник потому что сборка на VC6 работает несколько лет без проблем что будет под VC2003 пока не известно)
остальные dll и само приложение планирую собирать vs2005/2008
Пока я могу выбирать компилятор (мотивировав чем одна версия VC лучше другой)
Совершенно не понятно и пока нет нормальных идей как из x64 я буду использовать x86 приложение.
Re[3]: dll собранные разными компилятора в одном проекте
| От: | MasterZiv |
| Дата: | 07.03.09 10:33 |
| Оценка: |
sergey2b пишет:
> MZ>— ваши приложения НЕ используют C/С++ rumtime library
> как приложение или dll может не использовать rtl ?
Да легко ! Хочет — использует, не хочет — не использует.
Кстати, тут тоже есть нюанс, здесь были сообщения, что от 2003
начиная не использовать CRT не получается: компилятор сам
генерирует какие-то вызовы. Поищите, если интересно.
> В моем случаи вприложение на pure C++, все dll написанны на чистом C,
> все исключения обрабатываються внутри dlls, в функции dll передаються
> простые параметры типо DWORD, char* возвращаеться DWORD.
> Как в таком случаи различия версий rtl в dll могут повлиять?
В таком случае всё гораздо легче, но всё равно может и повлиять.
При предачи любых объектов, выделенных в хипе, из одной .dll в другую
и последующем удалении в другой, уже в другом хипе. Другие проблемы
тоже могут быть. Вообще, там куча нюансов, которые могут смещать
возможность решения в ту или иную сторону. Если .dll-и изолированые,
т.е. её создатели предприняли спрец. меры к тому, чтобы библиотека
работала в любом компиляторе, или не используют CRTL, то всё гораздо легче.
Вам надо это самому смотреть и думать и решать.
>> > Приложение должно собираться vs2008 часть dll используемых приложением
>> > должно собираться в vs6 (при желании можно собрать в vs2003), одна в 2005
Лучше соберите всё в одном компиляторе. Если есть возможность.
> Совершенно не понятно и пока нет нормальных идей как из x64 я буду
> использовать x86 приложение.
Источник: www.rsdn.org
C ++ с 2 компиляторами
У меня есть проект, который я хотел бы кодировать как на машине Ubuntu, так и на Windows. На Ubuntu я использую gcc, а в окнах я хотел бы использовать MSVC. Можно ли скомпилировать один и тот же код с двумя разными компиляторами? Или я буду сталкиваться с проблемами в будущем? Спасибо.
ipe369 05 апр. 2016, в 14:44
Поделиться
Да, компиляция с двумя независимыми компиляторами полезна. Убедитесь, что вы удалили предупреждающие сообщения, которые они могут выдавать (не отключая их, предпочтительно, понимая и исправляя их). Исходя из моего опыта, код, который хорошо компилируется с двух сторон, также работает с обеих сторон.
Yves Daoust 05 апр. 2016, в 12:34
Вы, вероятно, столкнетесь с проблемами в будущем, но это не должно вас останавливать. Вам может понадобиться использовать некоторый платформо-зависимый код, который обычно обрабатывается своего рода файлом «platform.h». Этот файл создает соответствующие определения на основе компилятора и платформы, поэтому вы не загромождаете свою кодовую базу определениями, специфичными для платформы.
Alex 05 апр. 2016, в 12:35
Lightness Races in Orbit 05 апр. 2016, в 12:35
Ixrec 05 апр. 2016, в 12:35
Tomáš Zato 05 апр. 2016, в 12:41
Lightness Races in Orbit 05 апр. 2016, в 13:19
Если одним из компиляторов является MSVC, то это абсолютно хорошая идея, если не по какой-либо другой причине, выполнять проверки работоспособности на нем.
Tommy Andersen 05 апр. 2016, в 13:45
Могу ли я просто переместить этот вопрос в нужное место? Или я должен был бы повторно спросить это?
ipe369 05 апр. 2016, в 17:01
Показать ещё 6 комментариев
Поделиться:
3 ответа
Лучший ответ
Это отличная идея. Раньше я обнаружил кучу ошибок в моем коде, которые я мог видеть только после переключения компиляторов.
Sam Varshavchik 05 апр. 2016, в 14:02
Поделиться
О, я никогда не думал, что они поймают разные ошибки, это замечательный момент! Было ли когда-нибудь время, когда вы не могли заставить код компилироваться на одном компиляторе только из-за различий в их работе? Я где-то читал, что msvc немного отличается от gcc, который более точно соответствует стандартам c ++.
ipe369 05 апр. 2016, в 12:34
Да. Даже тот же компилятор, но разные версии. Каждая последующая версия gcc имеет тенденцию быть менее терпимой к небольшим нарушениям правил C ++, которые более ранняя версия gcc имела тенденцию игнорировать.
Sam Varshavchik 05 апр. 2016, в 12:35
Вы всегда можете переписать код так, чтобы он компилировался на обеих платформах (необходимые изменения обычно очевидны). Немного страшный случай — они оба компилируются, но работает только один; ТЕСТ НА ОБОИХ ПЛАТФОРМАХ !! (Это обычно происходит, когда вы случайно ввели неопределенное поведение, но одна платформа делает то, что вы ожидали.)
Martin Bonner 05 апр. 2016, в 12:46
Показать ещё 1 комментарий
Если вы хотите скомпилировать для разных платформ, вам нужно скомпилировать их с разными компиляторами (даже если они являются разными версиями одного и того же компилятора).
Если вы скомпилируете как GCC, так и MSVC, вы обнаружите, что не можете использовать множество расширений, которые предоставляет каждый компилятор. Вы также найдете неприятности, такие как MSVC, подчеркивает фронт функций, таких как _open . В принципе, это сводится к «добро пожаловать в прекрасный мир портативного кодирования».
С другой стороны, как только вы начнете писать код для двух компиляторов, становится намного проще добавить третий. — и я бы рекомендовал добавить Clang в смесь в качестве дешевого и веселого статического анализа
Martin Bonner 05 апр. 2016, в 13:20
Поделиться
Не давайте людям gcc каких-либо ярких идей. Как добавление цели win32 в версию для Linux.
Sam Varshavchik 05 апр. 2016, в 12:37
Какая?
Вы имеете в виду, как Mingw?
Martin Bonner 05 апр. 2016, в 12:37
Разве Mingw не является родным портом Windows? Я имел в виду добавление цели кросс-компиляции win32 в версию для Linux. Что позволило бы технически использовать один и тот же компилятор для создания двоичных файлов ELF и win32.
Sam Varshavchik 05 апр. 2016, в 12:38
Это в основном gcc с генератором кода win32, который скомпилирован для win32. Теперь, как трудно заставить генератор кода работать в обычном gcc, я не знаю.
Martin Bonner 05 апр. 2016, в 12:43
ams 05 апр. 2016, в 13:27
Пометка, вы можете использовать одну версию кросс-компилятора с разными целями для разных платформ. «С другой стороны, Clang / LLVM изначально является кросс-компилятором, что означает, что один набор программ может компилироваться для всех целей путем установки параметра -target». — clang.llvm.org/docs/CrossCompilation.html
armb 17 авг. 2016, в 14:51
Показать ещё 4 комментария
Microsoft упрощает работу, позволяя вам скомпилировать код непосредственно из Visual Studio на Linux-сервере. Это довольно круто.
Rob K 05 апр. 2016, в 14:25
Поделиться
Ещё вопросы
Источник: overcoder.net
Развитие языков программирования
Синтаксис языка описывает систему правил написания различных языковых конструкций, а семантика языка программирования определяет смысл этих конструкций. Синтаксис языка программирования может быть описан с помощью НБФ-нотаций.
Семантика языка взаимосвязана с используемой вычислительной моделью . В настоящее время языки программирования в зависимости от применяемой вычислительной модели делятся на четыре основные группы:
- Процедурные языки, которые представляют собой последовательность выполняемых операторов . Если рассматривать состояние ПК как состояние ячеек памяти, то процедурный язык – это последовательность операторов, изменяющих значение одной или нескольких ячеек. К процедурным языкам относятся FORTRAN, C, Ada, Pascal, Smalltalk и некоторые другие. Процедурные языки иногда также называются императивными языками. Код программы на процедурном языке может быть записан следующим образом:
оperator1; operator2; operator3;
function1(function2( function3(beginning_date)));
if condition1 then operator1; if condition2 then operator2; if condition3 then operator3;
В настоящий момент наибольшее распространение получили языки, основанные на объектно-ориентированной модели. Они, реализуя процедурную модель построения языка, поддерживают аппликативность конструкций, позволяя представлять блок-схему выполнения структурированной программы как некоторый набор аппликативных функций.
Стандартизация языков программирования
Концепция языка программирования неотрывно связана с его реализацией. Для того чтобы компиляция одной и той же программы различными компиляторами всегда давала одинаковый результат, разрабатываются стандарты языков программирования. Существует ряд организаций, целенаправленно занимающихся вопросами стандартизации. Это Американский национальный институт стандартов ANSI (American National Standards Institute), Институт инженеров по электротехнике и электронике IEEE (Institute of Electrical and Electronic Engineers ), Организация международных стандартов ISO ( International Organization for Standardization ).
Как правило, при создании языка выпускается частный стандарт, определяемый разработчиками языка. Если язык получает широкое распространение, то со временем появляются различные версии компиляторов, которые не точно следуют частному стандарту. В большинстве случаев идет расширение зафиксированных первоначально возможностей языка.
Для приведения наиболее популярных реализаций языка в соответствие друг с другом разрабатывается согласительный стандарт. Очень важным фактором стандартизации языка программирования является своевременность появления стандарта – до широкого распространения языка и создания множества несовместимых реализаций.
В процессе развития языка могут появляться новые стандарты, отражающие современные нововведения. Так, язык FORTRAN первоначально был стандартизирован в 1966 году. В результате был издан стандарт FORTRAN 66. Далее этот стандарт несколько раз пересматривался (в 1977 году был выпущен FORTRAN 77, затем появился и FORTRAN 90).
Язык Java , ставший в последнее время весьма распространенным, постепенно был значительно расширен и модифицирован: новая спецификация получила название Java 2.
В процессе развития языка некоторые его конструкции и функции устаревают. Однако с целью обратной совместимости новые версии должны поддерживать и все устаревающие возможности. Это ведет к «разбуханию» компиляторов. В последнее время в реализациях введено понятие не рекомендуемой и устаревшей возможности.
В первом случае следующий стандарт еще будет поддерживать не рекомендуемую возможность, но может перевести ее в категорию устаревшей. Во втором случае стандарт может исключить поддержку возможности, объявленной ранее как устаревшая. Введение не рекомендуемых и устаревших возможностей предоставляет разработчикам временной интервал , в течение которого они могут модифицировать код в соответствии с новыми требованиями стандарта.
Среда проектирования
С развитием языков программирования совершенствовались и средства разработки программ – от режима командной строки до интегрированной среды проектирования. Такая среда предоставляет удобный графический интерфейс разработки и большой спектр сервисов, включающих управление версиями хранимых данных, утилиты просмотра и управления информацией, библиотеки классов, мастера создания шаблонов приложений и т.п.
Компилятор языка программирования выступает как составная часть среды проектирования. Сама программа наряду с конструкциями, предусмотренными стандартом, как правило, использует библиотечные функции и классы, предоставляемые средой проектирования. Так, интегрированная среда разработки VisualStudio. NET содержит библиотеку классов MFC (Microsoft Foundation Classes), значительно упрощающую процесс разработки приложений, использующих оконный интерфейс .
Интегрированная среда проектирования VisualStudio. NET позволяет создавать и компилировать приложения на языках C++, C#, Visual Basic и VisualJ. Для разработки приложений на языке С++ предназначается также среда CBuilder.
Для проектирования приложений на языке Object Pascal используется интегрированная среда проектирования Delphi.
Наиболее удобной средой разработки программ на языке Java является интегрированная среда проектирования JBuilder.
Источник: intuit.ru