Там конечно же и чистый C есть, но С++ без использования классов и прочих "апгрейдов" при равной эффективности настолько удобнее просто C, что все C-программы я пишу только на C++.
- - - Добавлено - - -
Для примера - небольшая программа на C++ и результат её компиляции:
Код:extern "C" unsigned int Swab_r16( unsigned int x ) { return (x << 8)|(x >> 8); }Код:.text .globl Swab_r16 ; -- Begin function Swab_r16 Swab_r16: ; @Swab_r16 ; BB#0: SwaB R0 Return ; -- End function .section ".note.GNU-stack","",@progbits
Хммм...
"Для примера - небольшая программа на C++ и результат её компиляции:"
Чем будет отличаться от эквивалентной "C"-программы ? При идентичных опциях компиляции и в этом же компиляторе но только с-режиме.
Можете привести результат компиляции ?
Никогда не запускал CLang в C-режиме (можете это сделать с приведённым исходником самостоятельно), но подозреваю, что с точки зрения стандарта C исходник может быть синтаксически некорректным. Собственно потому (главным образом) я и использую для C-программирования только C++, что там более адекватный (на мой взгляд) синтаксис, чем в нативном C.
С или C++ - это фронтенд, он превращает исходник в байткод, а потом уже ассемблер (бэкенд) компилирует этот байткод в код целевой машины. Если C-фронтенд не обидится на синтаксис исходника C++, то результирующий байткод вряд ли будет другим, а значит - результат последующего превращения байткода в код целевой машины будет аналогичным.
Последний раз редактировалось Patron; 16.07.2018 в 16:09.
Ок. Я не хочу "Святойвойны", но данный пример не говорит о тех или иных преимуществах с++ относительно С.
тк компиляция сего кода может быть идентична до "запятой". в частности openwatcom создаёт один и тот же исполняемый код.
ИМНО использовать С++, утверждая что он создаёт более оптимизированный код , чем просто С, не есть правильно.
Собственно "extern "C" говорит что "компилятор должен" компилировать сей текст как "язык С".
Другими словами Вы говорите что пишете на С++, а по факту пишете на чистом С.
И это как то не вяжется с утверждением " но С++ без использования классов и прочих "апгрейдов" при равной эффективности настолько удобнее просто C, что все C-программы я пишу только на C++"
ПС: Конечно в других частях программы Вы возможно и используете особенности языка С++, но приведённый пример явно не удачен для "демонстрации" плюсов языка С++.
Мож я что то не так понял ?
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
что-то мне помнится что это всего лишь указывает компилеру что ненадо извращать имена функций в результирующем obj как это принято делать в c++ и используется это исключительно для того чтоб obj генеренный "С" компилятором мог вызвать эту функцию без изменения в исходнике на "С" имени вызываемой функции по извращенческой схеме принятой в с++
- - - Добавлено - - -
про llvm интересно, на сколько я понимаю для написания крутого оптимизатора нужно четко представлять какие операции возможны в исполнителе для которого этот оптимизатор пишется... а так как llvm писался с учетом 32bit процессоров (да еще и не конкретного проца типа "cyrix 486sx25 rev32.22") то он оптимизирует с использованием каких-то общих для всех 32bit cpu операций а потому будет всегда отставать от таких компилеров типа open watcom. Но еще интереснее дело обстоит с pdp-11 учитывая что он довольно сильно отличается от "среднего 32bit" процессора... неужели есть шанс сделать лучше оптимизацию чем в древнем компиляторе на котором unix и был изначально скомпилен?
Единственный шанс сделать лучшую оптимизацию - проанализировать, на какие низкоуровневые (для языка) но всё ещё высокоуровневые (для процессора) операции можно странслировать исходный код - а потом оптимизировать ПРОЦЕССОР под эти операции Насколько я себе представляю, по этому пошли разработчики (группа под руководством Вирта) процессора для рабочей станции Lilith и разработчики (наши) процессора Кронос
Последний раз редактировалось Hunta; 07.07.2021 в 12:31.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)