Как построить связи между объектами

[_Bers]

Сообщение от pproger

2_Bers

с разморозкой. так работал только CFront. у крестов свой компилятор лет 20 минимум

Который однако ж не с нуля рисовали.

После компиляции нет никаких классов, и никаких иерархий.
Чистый процедурный императив.

Важно понимать, что ООП существует лишь в голове программиста. А компилятору, с некоторыми оговорками безразлично, что функция(объект), что объект.Функция()

[pproger]

2_Bers

После компиляции нет никаких классов, и никаких иерархий.
Чистый процедурный императив.

и что, из этого следует, что, цитирую

с++ компилятор, это на самом деле транслятор на язык си, и компилятор си.

?

[_Bers]

Сообщение от pproger

2_Bers

и что, из этого следует, что, цитирую

?

Ну понятно, что я утрирую. И на выхлопе будут обж, а не с файлы.

Смысл в том, что приплюснутый компиль обрабатывает c-style ничуть не хуже, чем сишный. Что неудивительно, учитывая историческое родство и языков, и их совместимость, а значит и общность используемых технологий.

С++ будет использовать все свое сишное наследие.

Просто на компилятор с++ ложится поддержка дополнительных технологий, таких как полиморфизм, всякие там шаблоны и прочее.

В любом случае, весь код будет приведет к обычному процедурному с-style, и обработан так, как буд то бы это обычный си-код

[Perchik71]

bers, тема.
Цитирую пост

COOLibin

если до сих пор непонятно откуда растут корни, поясняю полностью.
издревле повелось, что компиляторы с "продвинутых" и общеупотребительных языков программирования (asm, c, c++ и др.) разделяют код между т.н. юнитами компиляции (модулями). Каждый модуль может быть скомпилирован отдельно от других, производя на свет файл *.obj формата (универсальный формат), которые потом с помощью линкера подшиваются в один конечный исполняемых файл *.exe.
Так уж повелось, что в целях унификации фирмы-производители компиляторов старались сохранить формат *.obj единым для всех языков (по возможности), что даёт хорошую возможность создавать программы на из юнитов на разных языках программирования. Например модуль на чистопородном ASM можно было сшить в программу на чистопородном C.
Обратная совместимость с этой концепцией ввела в язык C++ некие "странные" на первый взгляд вещи.

*.obj файл исторически устроен сравнительно просто: в нём есть изолированные блоки откомпилированного уже машинного кода и данных, которые сдобрены "метками" - мнемоническими обозначениями, указывающими куда-нибудь внутрь сего дела. Причем в *.obj файле принципиально неизместно чем именно является метка - адресом глобальной переменной, или ф-ии - даже для линкера это непринципиально.

Со старыми языками всё это работало без проблем - экспортные ф-ии и переменные получали совпадающую со своим программным именем метку в *.obj файле и дальше всё шло как по маслу.

А вот в C++ дядя Страуструп ввел такую фичу, как перегруженные ф-ии. Это такие звери, которые хотя и называются в программе одинаково, но имеют разный набор параметров, а следовательно разные тела, наполнение и содержание.
И вот чтобы эту концепцию протянуть через *.obj файлы без конфликта меток пришлось ввести т.н. name mangling. С помощью этого механизма имена переменных и ф-ий в *.obj файлах дополняются специальными длинными абреввиатурами, чтобы исключить конфликт имен конечных перегруженных ф-ий.
Проблема в том, что этот механизм срабатывает всегда и объявив void some(); ты в *.obj файле получить можешь имя для ф-ии вроде _some_v_f. Чтобы нормально спрягать код на C++ с C или ASM, где name mangling отсутствует, введено extern "C", которое отключает сей механизм у экспортируемых или импортируемых имен переменных/ф-ий. Логично, что extern "C" ф-ии не могут быть перегружены.
Так понятно? =)

да я соглашусь что в .obj, но внутри них всё разное. Если бы так всё просто было.... небыло бы заморочек с использованием в Delphi наших сишных обж. А delphi обж ты не откроешь вовсе.

[_Bers]

Ну это ты уже затрагиваешь тему полиглотов)
Когда разные части проекта пишутся на разных языках.

Это уже очень крутой уровень. Я до такого покамест не дорос) Поэтому, ничего тебе про это сказать не могу.

[waleri]

Причем здесь формат OBJ файлов?
То, что name mangling не стандартизован является заслугой C++ комитета и к размеру и скорости выполнения отношения не имеет.

[Perchik71]

Сообщение от waleri

Причем здесь формат OBJ файлов?
То, что name mangling не стандартизован является заслугой C++ комитета и к размеру и скорости выполнения отношения не имеет.

Мы уже ушли от этой темы и пришли к тому, что всё уходит в c-style. читай посты waleri.
____
Я лишь хотел сказать этим постом, что да можно в c-style... допишите метку

extern "C" {....тут много кода...}

Но если эту метку не принимать, то там далеко не c-style.