2 вопроса по C и C++

как с его помощью сделать обвязку для вызова Qt из Си

Очевидно же, что никак.

В составе edg-шного фронтенда есть бекенд, генерирующий си.

ммм, а что мешает просто сделать вызов?

Ты можешь определить «прокси» функции которые не будет трогать Mangle обернув их в

extern "C" {}

А в обратную сторону посмотри имена через nn и просто прилинкуй нужный .o файлик

А автоматизировать?

Изначально объекты в Си реализовывались через макросы, из чего и развился С++.

Можно пруф? Может чья-то частная придумка?
Изначально объектов в Cи не было, были структуры.

А существуют ли компиляторы совренного С++ в Си?

Это невозможно впринципе.

Как ты сбираешься конвертировать тип auto, шаблоны, перегрузку операторов и т. п?

В С++ существует очень много конструктов которые макросами на Си не реализуешь.

Это невозможно впринципе.

В асемблер значит можно, а в си — нет?

конвертировать тип auto,

Auto — это не тип, а указание компилятору вывести тип автоматически. Компилятор выводит тип и подставляет его в сишный выхлоп.

шаблоны

Генерируешь множество функций под все инстансы шаблона.

перегрузку операторов

Оператор — это функция. Генерируешь разные функции под разные варианты типов аргументов.

Как со всем этим ^^^ по-твоему справляется «обычный» компилятор? На самом деле прикрутить бэкенд в любой язык — дело нехитрое.

Капитан Очевидность, ты?

Конечно, потенциально возможно написать транслятор С++ в Си с учетом всего перечисленного выше. Только он будет по сложности сопоставим с gcc/clang... А этот факт очень сильно добавляет веса вопросу «а зачем?». Учитывая, что сложность высока, а нужно это двум с половиной человекам, естественно, такого транслятора никто не сделал.

А существуют ли компиляторы совренного С++ в Си?

clang -c CPPtoC.cpp -o CPPtoC.bc -emit-llvm
clang -march=c  CPPtoC.bc -o CPPtoC.c

Это называется трансляцией. На примере Vala - плодит из высокоуровневого кода в C.

Капитан снова на связи. Нет никакой сложности сделать такой транслятор, потому что тебе не нужно писать его с нуля. Нужно сделать backend к тому же llvm/clang. У них например есть бэк, генерирующий LLVM IR, а сделать из него си — проще пареной репы. Другой дело, что выхлоп будет иметь мало общего с исходным плюсовым кодом (но об этом ТС и не просил), и, я не могу не согласиться, это нафиг никому не нужно.

Ну вызови через манглинг. Это не портабельно, но возможно

А существуют ли компиляторы совренного С++ в Си?

Попробуй через llvm: https://github.com/JuliaComputing/llvm-cbe

А можно пример вызова который ты хочешь сделать?

Можно пруф? Может чья-то частная придумка?

Реализация ООП в GTK и краткие упоминания в разных предисловиях и биографиях Страуструпа, что он отказался от такого подхода и с самого начала написал для C++ новый компилятор.

Нужны конкретные имена и названия?

https://github.com/JuliaComputing/llvm-cbe

Спасибо.

clang -c CPPtoC.cpp -o CPPtoC.bc -emit-llvm

clang -march=c CPPtoC.bc -o CPPtoC.c

Спасибо.

Это называется трансляцией.

Это я знаю. Я спрашивал, какие трансляторы так умеют.

А можно пример вызова который ты хочешь сделать?

С конкретным примером спрашивал бы в Development :)

Ну вызови через манглинг. Это не портабельно, но возможно

Это как? Определить, как конкретный компилятор преобразует имя вызова метода и какие требуются параметры в стеке, и вызывать их? Я спрашивал про автоматизацию.

В пределах одного abi можно автоматизировать

Реализация ООП в GTK и краткие упоминания в разных предисловиях и биографиях Страуструпа, что он отказался от такого подхода и с самого начала написал для C++ новый компилятор.
Нужны конкретные имена и названия?

Нет, не нужны. Масштаб понятен.

Это подтверждает, что фраза «Изначально объекты в Си реализовывались через макросы» не корректна. Не реализовывались в Си объекты никак. Была попытка эмулировать ООП в одной конкретной библиотеке, и сообществом этот подход принят не был. А записки Страуструпа вообще не в счет: черновики есть черновики.

Капитан снова на связи. Нет никакой сложности сделать такой транслятор, потому что тебе не нужно писать его с нуля. Нужно сделать backend к тому же llvm/clang. У них например есть бэк, генерирующий LLVM IR, а сделать из него си — проще пареной репы. Другой дело, что выхлоп будет иметь мало общего с исходным плюсовым кодом (но об этом ТС и не просил), и, я не могу не согласиться, это нафиг никому не нужно.

Вероятность того, что что-то реализуют, прямо пропорциональна нужности, и обратно пропорциональна сложности.

Если всё так просто, как ты говоришь, значит это нужно еще меньшему количеству людей, чем я предполагал изначально.

Была попытка эмулировать ООП в одной конкретной библиотеке,

Доказывающая принципиальную возможность.

и сообществом этот подход принят не был.

C++ удобнее.

Objective-C тоже так работает.