C++ Отдельные компиляторы для классов (vtables)?

Мне было интересно, каковы последствия для компиляции класса A с одним компилятором, который не допускает множественного наследования и компиляции класса B, который его поддерживает (и класса B, полученного из класса A).C++ Отдельные компиляторы для классов (vtables)?

Я действительно не понимаю процесс связывания ... можно ли использовать оба вместе? Какие недостатки существуют для использования отдельных компиляторов в этой ситуации с помощью vtables? Было бы невозможно, чтобы код, использующий класс B, функционировал правильно?

Спасибо.

источник

2009-11-05 ash

Это можно суммировать следующим образом: Каждый изготовитель компилятора может определить собственный ABI. Поскольку различия в ABI делают код из одного компилятора непригодным для другого, это делает эти процессы непригодными. Фактически использование кода, скомпилированного с одним и тем же компилятором и разными флагами, может привести к одной и той же проблеме (двоичные файлы debug и release не совместимы с некоторыми компиляторами). Поэтому технически все единицы компиляции должны быть скомпилированы с одним и тем же компилятором с использованием тех же флагов (в противном случае вы просите о проблемах). –

Как правило, не компилировать части вашей программы на C++ с различными компиляторами.

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

См документ о коверкая name_mangling

источник

2009-11-05 13:29:21

Кроме того, реализация vtable, обработка исключений и т. Д. (Весь C++ ABI) могут быть разными. – sellibitze

Спасибо за хед-ап. Я никогда этого не сделаю. – ash

Это можно сделать, если вы используете общие объекты/библиотеки DLL. Тогда существует общее соглашение об объединении, так что разные компиляторы могут работать вместе. Если вы используете DLL в своем приложении у внешнего поставщика, вы не знаете, какой компилятор они использовали. Вам придется разбить приложение на «общие» объекты/библиотеки DLL. –

расположение объектов (виртуальные таблицы расположение указателя, формат, виртуальные таблицы размещения подобъектов и т.д.) не гарантируется быть одинаковым между составителями.

источник

2009-11-05 13:35:40

Это не просто классы, которые не смогут разговаривать друг с другом. Голые функции, объявленные в заголовке, но скомпилированные только одним из компиляторов, будут невидимы для другого компилятора из-за изменения имени.

Кроме того, любые статические классы/члены классов, скомпилированные компилятором, который НЕ компилирует main(), не будут правильно инициализироваться, потому что время выполнения этого компилятора не будет выполнено. Даже такие вещи, как 64-разрядная длинная арифметика (на 32-битных платформах), могут быть неправильно связаны из-за противоречивых библиотек времени выполнения.

источник

2009-11-05 13:35:46 jmucchiello

В качестве добавления к сообщению Arkaitz в выше, вы можете найти другие вопросы, которые могли бы остановить код, работающие вместе с единиц компиляции, построенных с разными компиляторами:

вопросов размера данных (например, один компилятор использует 32-битный Интс, в другие 64 бит) выравнивание
данные вопросы
проблемы с кучей памяти

в принципе в любом месте, что стандарты C++/C не очень специфичен о том, оставляет возможность для различий между компиляторами и, следовательно, сфера для проблем, связанных с их смещением

источник

2009-11-05 13:37:30 pxb

C++ Отдельные компиляторы для классов (vtables)?

ответ

Смежные вопросы