Developing.ru

Язык программирования Си создавался с конкретной целью: это язык для написания портируемых программ, при этом максимально эффективный в плане быстродействия, сопоставимый с ассемблером (который на всех аппаратных платформах разный). Удобство программирования в Си - это вещь третьестепенная, он действительно не очень удобен. Выполняются только те действия, которые ты прописал явно - именно поэтому строки и массивы реализованы так дубово и неказисто.
Если поставить перед собой такую задачу и писать в соответствии со стандартом ANSI C, то на Си можно написать портируемую программу или библиотеку функций. Эту программу возможно откомпилировать практически на любом типе процессора - компилятор Си есть везде. И она будет работать. Примеров неисчислимое количество (zlib, libpng и так далее).
Итак, Си - это язык низкоуровневого программирования, предназначенный для создания портируемых программ и библиотек функций. Его появление было настоящей революцией, потому что он позволил отвязать программы от конкретной процессорной архитектуры, практически ничего не потеряв в производительности и быстродействии, в сравнении с ассемблером.
Эту нишу он занял навсегда и пребудет в ней навсегда. Нет смысла придумывать что-то ещё.

Изначально создатели языка Си и системы Unix предполагали, что возникнут другие языки, более удобные для программистов (каждый язык со своей специализацией). Для каждого такого языка, на Си будет написан транслятор (не компилятор), который транслирует исходник с этого языка опять же на Си, а не в исполняемый код. И уже этот промежуточный Си-текст транслируется Си-компилятором в бинарный исполняемый файл. Такова была изначальная философия системы Unix: все программы портируемы и все языки надстраиваются над базовым языком Си.

Улучшайзер Бьёрн Страуструп и его Си++

И вот, пользуясь тем, что язык Си многие знают, некто Бьёрн Страуструп решил его "проапгрейдить": он прилепил дополнительные фичи (большей частью совершенно идиотские - вроде перегрузки стандартных операторов) и добавил "объектно-ориентированность". Ну, про "объектно-ориентированность" я напишу как-нибудь потом, это отдельный разговор, а в целом получили следующее: в язык введены неявные скрытые механизмы, которые не работают одинаково на разных платформах, портируемые программы писать невозможно, и в то же время язык неудобен для высокоуровневого программирования, как и Си. Компиляторы Си++ намного сложнее, чем компилятор Си, и есть не везде. В основном Си++ используют, потому что под него написаны библиотеки классов (как правило привязанные к определённой платформе и операционной системе).
Теряюсь в догадках, кому понадобилось раскручивать такое скотоложество (другого слова не подберу). Деньги в это вбуханы чудовищные - помню по той рекламной кампании, которая сопровождала продвижение Си++.

Тем не менее, Си++ используют и пишут на нём программы. Ну просто человек ко всему привыкает.

Боюсь что большинство программистов, которые говорят что пишут на "C++", на сам деле пишут на некой смеси двух языков C/C++. А вобще это святые войны. Лучше отвечу чужими словами:

Автор: 0xffa500
Представим что есть у нас 4 пипла. У каждого есть 3 доски: дубовая, сосновая, дсп.
У каждого есть гвозди и шурупы. У 1го человека - молоток. У 2го - отвертка, у 3го - механическая отвертка с прокруткой и у 4го электро-шуруповерт.
У всех задача ОДНА: вогнать в доски по гвоздю и шурупу.
Первый легко и быстро вгонит молотком гвоздь и шуруп во все доски, но при этом доска их дсп треснет.
Второй одинаково хорошо вгонит шурупы во все 3 доски, при этом он не сможет вогнать гвоздь.
3й Быстрее 2го вгонит шурупы, с гвоздями та же ситуация.
4й электрошуруповертом без особых усилий вгонит шурупы и быстрее предыдущих 2х, но при этом сам шуруповерт не сможет хорошо затянуть шуруп до конца без помощи человека, не хватит силы электромотора.

Каждый из них может одинаково хорошо делать свою работу своим инструментом, при этом у каждый из них может чего-то не мочь делать своим инструментом, ибо этот ИНСТРУМЕНТ НЕ ПРИСПОСОБЛЕН для данных целей, и каждый из них имея кривые руки испортит одинаково хорошо и материал и инструмент!
Мораль сей басни такова: языки програмирования - те же инструменты.

Не стоит обсирать инструмент, особенно если не до конца понимаешь зачем он создан!!!

НАдо за легкость расплачиваться. Не бывает идеала.

Только не забывай что каждый инструмент для своих задач, и писать на ASM офис ты не будешь...
Для некоторых хочу сказать что моей целью не было показаться "Шибко умным" и кого-то чему-то учить.
Я просто хотел донести до людей то, что многие реально не понимают.

Беред. Си - язык высокого уровня, он, в отличие даже от паскаля, не имеет вообще ни одного низкоуровневого оператора, например, вызвать прерывание на нём можно только через встроенный ассемблер, а на паскале это делается помимо ассемблера. Язык ассемблера, наоборот, целиком низкого уровня, в нём не предусмотрено ни одной высокоуровневой мнемоники. Так что на язык ассемблера c можно только компилировать, а не сопоставить одно другому.

Язык ассемблера, наоборот, целиком низкого уровня, в нём не предусмотрено ни одной высокоуровневой мнемоники.

Современные асматики пишут на масме, стиль написания на котором приближается к высокоуровневым языкам из-за частого использования макрокоманд. Тем более, в прилжениях Windows, где 80% кода сводится к общению с функциями WinAPI

Макрокоманды ни чего общего не имеют с высокоуровневыми языками.

И если 20% и даже 0,08% сводится к обращениям к системе, то прогу можно легко заменить, систему может и юзверь юзать.

И уровень языка не связан с тем, сколько именно опкодов прячется под одной мнемоникой макрокоманды, она всё равно из них и состоит. Какая разница, соответствует ли одному опкоду процессора, или COPY (40000, 16384, 6144) длинной цепочке, помещающей три числа в регистры и потом копирующей данные оперцией MOVS с репером? Уровень языка определяется уровнем абстракции данных, если мне не надо задумываться над тем, складывается ли uint32_t с помощью 32-х битных регистров за одну операцию сложения, за две операции сложения и сложения с переносом с помощью 16-ти битных регистров, или же для этого 4 раза юзаются однобайтные регистры, то уровень высокий. Макрокоманда определяет это однозначно, там, где определяется сама макрокоманда, а на c за это отвечает соответствующая конкретному процессору версия компилятора. А может сложение charов происходит в 128-ми битных регистрах, дополняемых копиями знаковых разрядов и только при доступе к памяти обрезаемых до одного байта? А может и не всегда обрезаемых, а при выравнивании struct с charом на границу 128-ми бит заполнители так и пишутся старшими байтами регистра? Мне опять таки не надо об этом задумываться на c, а на макроасме надо. И какой конкретно регистр будет использован для сложения я могу даже не знать, а при использовании макрокоманды я должен учитывать, что если такая то макрокоманда юзается в паре с той, юзая одни регистры, то разбивать пару вот этой макрокомандой можно, так как она сохраняет эти регистры не тронутыми, а этой нельзя, так как она их меняет для использования в паре вон с той. На c можно вообще не думать и даже не знать, какой аппаратурой будет исполнена такая то инструкция, в рамках достаточности оперативной памяти и быстродействия перекомпилировать программу хоть для z80, не меняя вообще ничего - не проблема и меня не волнует, что там меньше регистров в каждом банке, зато их два вместо одного. Нет компилятора? А кроскпомпилятор? Нет и его? Ну тогда асм в помощь для разработки компилятора, а потом можно про архитектуру забыть. А на макроассемблере придётся архитектуру учитывать при разработки каждой софтины, а не только самого ассемблера, а переносимость даже при пересборке поддерживается только в плане смены раскладки тех же операций на другие опкоды. И для того, чтоб выставить определённые цвета консоли и определённый вид каретки, мне не надо думать о том, в какие регистры что надо записать и какой номер прерывания вызвать, это делается оболочечной функцией, а в неё уже завёрнут кусок на асме, который уже сохраняет регистры в стек, раскладывает по ним параметры, прерывает, потом восстанавливает регистры из стека. Это уже делается на другом языке, а на самом c только вызов функции и она даже может быть системной, или библиотечной. Мне не надо на c думать, по каким смещениям от указателя стека лежат параметры функции и как зовут сам указатель. И в каком внутреннем формате закодированы floatы мне тоже думать не надо. Я могу не учитывать порядок не только битов, но и байтов и слов в тех числах, которые не влезают в регистр. Могу не знать, есть ли вообще в процессоре команда умножения и какие адресации поддерживает каждая команда. А на масме мне надо знать, что z80 умножать не умеет и сначала реализовать умножение другими операциями, а только потом юзать. На c же я risc от cisc могу не отличать и вообще думать, будто компьютер не имеет адресуемых регистров вообще, а процессор не содержит арифметико-логического устройства, а является лишь устройством управления, АЛУ же распределено по оперативе, в которой и выполняется вся обработка инфы. На масме этот бред не даст писать вообще, а на c не будет мешать, а лично мне даже приходится временно забывать архитектуру, заменяя знания архитектуры именно этим бредом, чтоб вообще иметь возможность писать на c/c++ и на бейсике, хотя при этом я ещё помню, что умножение и деление занимают больше тактов, чем сложение/вычитание и если стоит вопрос о том, сложить/вычесть ли несколько произведений с одним совпадающим множителем, или несколько частных с совпадающим делителем, или делимым, или же вынести умножение, или деление за скобки, получив произведение, или частное с участием всей суммы/разности, всегда выношу. А кое кому приходится объяснять даже разницу между декрементом и .

BulldozerBSG писал(а):Первый легко и быстро вгонит молотком гвоздь и шуруп во все доски, но при этом доска их дсп треснет.

Бред. Гвоздь он ещё забьёт, а шуруп у него никуда не залезет, в конце концов он сломает и молоток, и шурупы, и доски, купит новые гвозди, доски и шурупы, кое как забьёт гвозди кулаками и потратит десятки лет на вкручивание шурупов пальцами. А вот четвёртый и шурупы легко и быстро закрутит, и гвозди легко вставит пальцами в отверстия, так как шупруповёрт - это ещё и дрель. Правда гвозди у него также легко выпадут, но как то задача будет решена, при этом быстро, легко и просто, а для качественного решения нужен в пару к шуруповёрту молоток, либо гвозди надо заменить тоже шурупами, что будет ещё качественней.

BulldozerBSG писал(а):4й электрошуруповертом без особых усилий вгонит шурупы и быстрее предыдущих 2х, но при этом сам шуруповерт не сможет хорошо затянуть шуруп до конца без помощи человека, не хватит силы электромотора.

Во-первых у мотора нет силы, а есть момент. Во-вторых нужен как раз момент, а не сила. В-третьих у мотора он больше, поэтому как раз возможности человека затяг и ограничат: вместо дальнейшего затягивания будет проворачиваться рука. В четвёртых этого затяга как раз достаточно.

BulldozerBSG писал(а):Боюсь что большинство программистов, которые говорят что пишут на "C++", на сам деле пишут на некой смеси двух языков C/C++. А вобще это святые войны. Лучше отвечу чужими словами:

На смеси не пишет ни кто. Или человек знает c++ и пишет на нём, или он его не знает и пишет на общем подмножестве. Третьего не дано, это всё таки не русский с польским и даже не немецкий с ивритом.