Почему Си - хорошо, а Си++ - плохо
Язык программирования Си создавался с конкретной целью: это язык для написания портируемых программ, при этом максимально эффективный в плане быстродействия, сопоставимый с ассемблером (который на всех аппаратных платформах разный). Удобство программирования в Си - это вещь третьестепенная, он действительно не очень удобен. Выполняются только те действия, которые программист прописал явно - именно поэтому строки и массивы реализованы так дубово и неказисто.
Если поставить перед собой такую задачу и писать в соответствии со стандартом ANSI C, то на Си можно написать портируемую программу или библиотеку функций. Эту программу возможно откомпилировать практически на любом типе процессора - компилятор Си есть везде. И она будет работать. Примеров неисчислимое количество (zlib, libpng и так далее).
Итак, Си - это язык низкоуровневого программирования, предназначенный для создания портируемых программ и библиотек функций. Его создание было настоящей революцией, потому что он позволил отвязать программы от конкретной процессорной архитектуры, практически ничего не потеряв в производительности и быстродействии, в сравнении с ассемблером.
Эту нишу он занял навсегда и пребудет в ней навсегда. Нет смысла придумывать что-то ещё.
Изначально создатели языка Си и системы Unix предполагали, что возникнут другие языки, более удобные для программистов (каждый язык со своей специализацией). Для каждого такого языка, на Си будет написан транслятор (не компилятор), который транслирует исходник с этого языка опять же на Си, а не в исполняемый код. И уже этот промежуточный Си-текст транслируется Си-компилятором в бинарный исполняемый файл. Такова была изначальная философия системы Unix: все программы портируемы и все языки надстраиваются над базовым языком Си.
Улучшайзер Бьёрн Страуструп и его Си++
И вот, пользуясь тем, что язык Си многие знают, некто Бьёрн Страуструп решил его "проапгрейдить": он прилепил дополнительные фичи (большей частью совершенно идиотские - вроде перегрузки стандартных операторов) и добавил "объектно-ориентированность". Ну, что касается "объектно-ориентированности" - это отдельный разговор, а в целом получили следующее: в язык введены неявные скрытые механизмы, которые не работают одинаково на разных платформах, портируемые программы писать невозможно, и в то же время язык неудобен для высокоуровневого программирования, как и Си. Компиляторы Си++ намного сложнее, чем компилятор Си, и есть не везде. В основном Си++ используют, потому что под него написаны библиотеки классов (как правило привязанные к определённой платформе и операционной системе).
Теряюсь в догадках, кому понадобилось раскручивать такое безобразие. Деньги в это вбуханы чудовищные - помню по той рекламной кампании, которая сопровождала продвижение Си++.
Тем не менее, Си++ используют и пишут на нём программы. Ну просто человек ко всему привыкает.
Оставить комментарий
Комментарии
Описывать преимущества Ди перед Си++ не буду - они очень высоки.
Что касается Динрус, то я лично занимаюсь его разработкой и хотел бы найти помощников в этом деле.
Си входит сюда же, как составная часть.
Вот ряд сишных функций в Динрус:
extern (C):
цел удали(in ткст фимя);
alias удали remove;
цел переименуй(in ткст из, in ткст в);
alias переименуй rename;
фук времфл();
alias времфл tmpfile;
ткст времим(ткст s);
alias времим tmpnam;
цел закройфл(фук поток);
alias закройфл fclose;
цел слейфл(фук поток);
alias слейфл fflush;
фук откройфл(in ткст фимя, in ткст режим);
alias откройфл fopen;
фук переоткройфл(in ткст фимя, in ткст режим, фук поток);
alias переоткройфл freopen;
проц устбуф(фук поток, ткст буф);
alias устбуф setbuf;
цел уствбуф(фук поток, ткст буф, цел режим, т_мера размер);
alias уствбуф setvbuf;
цел вфвыводф(фук поток, in ткст формат, спис_ва арг);
alias вфвыводф vfprintf;
цел вфсканф(фук поток, in ткст формат, спис_ва арг);
alias вфсканф vfscanf;
цел всвыводф(ткст s, in ткст формат, спис_ва арг);
alias всвыводф vsprintf;
цел вссканф(in ткст s, in ткст формат, спис_ва арг);
alias вссканф vsscanf;
цел ввыводф(in ткст формат, спис_ва арг);
alias ввыводф vprinf;
цел всканф(in ткст формат, спис_ва арг);
alias всканф vscanf;
цел берисфл(фук поток);
alias берисфл fgetc;
цел вставьсфл(цел c, фук поток);
alias вставьсфл fputc;
ткст дайтфл(ткст s, цел n, фук поток);
alias дайтфл fgets;
цел вставьтфл(in ткст s, фук поток);
alias вставьтфл fputs;
ткст дайт(ткст s);
alias дайт gets;
цел вставьт(in ткст s);
alias вставьт puts;
цел отдайс(цел c, фук поток);
alias отдайс ungetc;
т_мера читайфл(ук указат, т_мера размер, т_мера nmemb, фук поток);
alias читайфл fread;
т_мера пишифл(in ук указат, т_мера размер, т_мера nmemb, фук поток);
alias пишифл fwrite;
цел дайпозфл(фук поток, цел * поз);
alias дайпозфл fgetpos;
цел устпозфл(фук поток, in цел* поз);
alias устпозфл fsetpos;
Быстродействие определяется реализацией компилятора/оптимизатора и стандартных библиотек. Сам по себе язык не может быть тормозным или быстрым.
>>Если поставить перед собой такую задачу и писать в соответствии со стандартом ANSI C, то на Си можно написать портируемую программу или библиотеку функций.
Аргумент отстойный. Стандарт ANSI C слишком мал и даже сетевой ввод/вывод в себя не включает. О какой портируемости речь? Для утилит уровня grep/echo/cat? Потому что никакое графическое приложение на ANSI C написать не получится. Кроссплатформенность в библиотеках типа qt/gtk достигается за счет подачи разного кода разным архитектурам. Нет причин, по которым то же самое нельзя сделать и в C++.
zlib и libpng плохие примеры, поскольку это вспомогательные библиотеки, которым от системы нужно разве что выделение памяти или файловый ввод/вывод - это должно быть в ЛЮБОЙ стандартной библиотеке любого языка программирования. Остальное в них составляют чистейшие алгоритмы.
>>Компиляторы Си++ намного сложнее, чем компилятор Си, и есть не везде.
Компиляторов куча, и под самое разное. Тот же GCC может быть легко портирован на нужную архитектуру. Поясняю принцип его работы - код на C++ сначала транслируется в ассемблер целевой архитектуры, после чего к нему "пришивается" OS-зависимый код (типа инициализации при старте и т.д.), после чего все это линкуется в нужный исполняемый формат, вместе с портированными стандартными библиотеками.
Также автору и всем, кто еще не слышал о LLVM и компиляторе Clang - рекомендую ознакомиться.
>>В основном Си++ используют, потому что под него написаны библиотеки классов (как правило привязанные к определённой платформе и операционной системе).
Внезапно, для использования C++ библиотек совсем не обязательно писать на C++. Достаточно написать заглушку классов в процедуры на C. Зачатки ООП есть в библиотеке Glib (не путать с Glibc), которую используют и в проектах на C.
Что касается библиотеки классов - скажу с ходу - они облегчают нам жизнь.
поэтому не вижу смысла говорить что-то плохое в адрес с++, да с учетом того, что если кому то не нравится на нем писать - почти всегда можно обойтись с.
2. все таки си до ассемблера далековато, с нашими то кривыми оптимизаторами, но немного мусорных инструкций не что по сравнению с мощью языка.
3. си не умрет никогда сколько бы не рекламировали и не придумывали новые специализированные языки.