проблемы с компиляцией программы

[alex]

Значит скомпилировал бибилотеку Qt с MSVS. а при попытке скомпилировать в ней проект с помощью MinGW получил ошибку.Почему нельзя использовать разные компиляторы?

[Fregloin]

Потому что разные компиляторы по разному компилируют ...

[Alex Custov]

Значит скомпилировал бибилотеку Qt с MSVS. а при попытке скомпилировать в ней проект с помощью MinGW получил ошибку.Почему нельзя использовать разные компиляторы?

Потому что нужно писать стандартный код.

[Bepec]

Компиляторы должны придерживаться стандарта языка.

Компиляторы аля MinGW позволяют отступать от стандарта.

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

[Dancing_on_water]

Значит скомпилировал бибилотеку Qt с MSVS. а при попытке скомпилировать в ней проект с помощью MinGW получил ошибку.Почему нельзя использовать разные компиляторы?

Ты пытаешься с помощью MinGW скомпилировать проект, используя dll скомпилированные в MSVC?

[alex]

Значит скомпилировал бибилотеку Qt с MSVS. а при попытке скомпилировать в ней проект с помощью MinGW получил ошибку.Почему нельзя использовать разные компиляторы?

а вы правы но я все равно не понимаю. Поясните на примерах ваши слова

[Bepec]

Код:

int a = *;//ввод пользователем.
int b[a];

MinGW пропустит такой код и скомпилирует.
MS такой код обругает матом и убьёт жалкую попытку скомпилировать.

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

[Dancing_on_water]

Судя по цитате это обращение ко мне. Но я ничего не понял

Верес: по стандарту много что должно быть и чего компиляторы делают\не делают. Но Qt написан так, что в хедерах  API нет (по крайне мере я не встречал) зависимости от компиляторов. т.е. все платформо\компиляторо- зависимый код уде откомпилирован и спрятан в dll. Здесь дело здесь в другом.

Формат dll описан для вызова функций, наподобие паскалевских или сишных,  и все компиляторы спокойно могу юзать dll, скомпилированные в другом компиляторе, если там только функции. А вот насчет классов, то формат это не регламентирует. И каждый компилятор решает задачу загрузки\линковки по-своему.

Думаю (но не уверен, т.к. не копал тему глубоко), что именно в этом причина.
P.S. сплошь рядом присутствуют проблемы при загрузке dll с классами собранные не просто разными компиляторами, но и разными версиями одного и тогоже компилятора.

[mutineer]

Формат dll описан для вызова функций, наподобие паскалевских или сишных,  и все компиляторы спокойно могу юзать dll, скомпилированные в другом компиляторе, если там только функции.

Могут спокойно, если у них совпадает формат вызова (порядок заталкивания параметров в стек, etc) либо он указан явно и одинаков

[Bepec]

Проще выражаясь - хрен что ТС скомпилит, если библиотеки скомпилены другим компилятором.

[Igors]

Код:

int a = *;//ввод пользователем.
int b[a];

MinGW пропустит такой код и скомпилирует.
MS такой код обругает матом и убьёт жалкую попытку скомпилировать.

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

Насколько мне известно, в стандарт эта удобная вещичка не входит, но практически все компиляторы ее поддерживают, может MSVC единственный что нет. Однако какое это отношение имеет к скомпилированной статик либе? Код создан и в либе сидит, линкеру может помешать только отсутствие внешних ссылок. "Удобный массив" создается через alloca (именно "a" в конце). Если MSVC видит alloca в какой-то из своих либ - то все слинкуется и будет работать. Если же подключается dll - то все еще проще, совпадали бы правила вызова как уже сказали выше.

Однако если в дело вмешивается напр STL, то все, приплыли. Потому что реализация того же std::vector различна в разных компиляторах, эта внешняя ссылка остается неразрешенной, должен быть только свой/родной vector.

Практически вывод тот же: компилируйте все однообразно и не ищите приключений 

 

[alex]

спасибо вам магистры за информацию

[Old]

Однако если в дело вмешивается напр STL, то все, приплыли. Потому что реализация того же std::vector различна в разных компиляторах, эта внешняя ссылка остается неразрешенной, должен быть только свой/родной vector.

Не реализация, а именование (mangling) функций и методов различаются у разных компиляторов.

[Igors]

Не реализация, а именование (mangling) функций и методов различаются у разных компиляторов.

Поля данных разные. А у MSVC они могут быть разными даже для debug/release и зависеть от директив компилятора

[Old]

Поля данных разные. А у MSVC они могут быть разными даже для debug/release и зависеть от директив компилятора

Не знаю, что имеется ввиду под "поля данных"... Есть соглашения о вызовах, если их соблюдать то все будет работать, методы будут спокойно получать входные параметры.
Если имеется ввиду внутренняя структура объектов классов, то здесь тоже все будет нормально. Главное не создавать объект конструктором из одной библиотек, а для работы использовать методы из другой. Ну до такого вряд-ли кто-то додумается.