C или C++?
Существуют два диаметрально противоположенных, но одинаково распространенных мнения, которые можно выразить как «C++ это C с классами» и «C++ и C — разные языки программирования». В общем-то, не важно, какого мнения придерживаться, но интересно иное — в каких случаях какой из этих языков (или вариантов языка) предпочтительнее.
При этом я не хочу начинать сравнение объектно-ориентированного и структурного подходов к созданию программного обеспечения, потому что очень часто в подобных дискуссиях можно услышать фразу вида «недостаточная объектно-ориентированность языка программирования», а она, на мой взгляд, неверна: при проектировании системы «объектно-ориентированность языка программирования» важной роли не играет — «объектно-ориентированно» программировать можно практически на любом языке программирования. Другое дело, что дополнительные средства языка, поддерживающие создание и использование объектов, сокращают количество соответствующих строчек кода и уменьшают вероятность ошибок, но в идеале это не важно.
Кардинальная разница между C и C++ не в классах или шаблонах по отдельности, а в общей идеологии: C позволяет программистам максимально контролировать (для языка программирования высокого уровня) программу, а C++ идет по пути усложнения компилятора, чтобы позволить программисту писать программу как ему будет «удобно». При этом, опять же, в идеальном случае, компилятор языка поймет желание программиста и полученный код будет все равно максимально эффективным (или близким к эффективному). С одной стороны, подход C++, не может не вызвать интереса и одобрения, так как дает возможность создания эффективных программ не снижая при этом их читабельность или удобство наращивания. Но с другой стороны — повышение сложности компилятора сопряжено с различными трудностями, многие из которых до сих пор не преодолены.
Когда я только начинал изучать C++ (это было, наверное, лет 6-7 тому назад), я был удивлен большому количеству резко отрицательных мнений о нем у профессиональных программистов. Тогда мне это было непонятно, что, в общем, неудивительно: Бьерн Страуструп не только пошел по пути усложнения компилятора, но и по пути усложнения языка программирования, так что изучение C++ это очень долгосрочный процесс и, наверное, на сегодняшний день это самый сложный язык программирования. А так как противопоставить что-либо языку программирования можно только после того, как придет понимание основных идей и большинства конструкций языка, а так же после выполнения крупных проектов на нем, то и время детского воодушевления и радости при виде мощного инструмента (каким является C++) значительно больше, чем у других языков программирования.
Несмотря на то, что за эти 7 лет C++ прошел достаточно большой путь и сильно изменился, мне кажется что источник тех нареканий, которые имеют смысл, остался. Хочется отметить, что есть большое количество нареканий относительно бесcмысленных, на мой взгляд, таких как уже упомянутый странный термин «малая объектно-ориентированность». Очень часто можно услышать, что «C++ это не Smalltalk». Странное суждение: если программисту больше нравится Smalltalk, то на нем и надо программировать.
Корень же большинства бед, связанных с C++, кроется как раз в усложнении компилятора (несмотря на то, что выше это усложнение преподносилось в качестве преимущества): чем сложнее программа (в данном случае, компилятор), тем больше вероятность того, что в ней будет ошибка.
На самом деле, конечно же, если программа перестает работать, то жаловаться на инструмент разработки надо в последнюю очередь, а сначала следует попытаться найти ошибку в своем исходном коде. Но чем больше становится программа, чем сильнее она разрастается, тем все больше и больше вероятность того, что ошибка в компиляторе скажется на работе вашей программы. Это было бы еще полбеды и особенности «своего» компилятора программисту следует знать, но компиляторов C++ достаточно много и каждый из них обладает своими собственными достоинствами и недостатками, результатом которых может стать невозможность сборки проекта под какой-либо средой программирования, отличной от первоначальной. Я не имею в виду сложность написания универсально переносимых программ, работающих под любой операционной системой, совсем нет. Просто так как написать компилятор C проще, чем C++, и так как сам язык программирования C имеет меньшее количество скользких мест, чем C++, то два разных компилятора C (разных производителей) будут больше похожи друг на друга по поведению, чем два компилятора C++.
Кроме компилятора, большую сложность при программировании на C++ вызывает использование STL. Несомненно, библиотека шаблонов очень удобна и полезна, но это в идеале. К примеру, очень часты случаи, когда смена поставляемой с компилятором STL на STLport, приводит к тому, что программа начинает работать стабильнее.
Конечно же, проблемы, связанные с ошибками в компиляторах, проявляются очень редко. Собственно поэтому можно уже сейчас оценить круг задач, которые лучше решать при помощи C++, чем C (при наличии, конечно же, хороших навыков программирования в обоих языках): это практически все программы, от которых не требуется беспрерывная работа 24 часа в сутки. Очень неприятно обнаружить, что программа, которая писалась и отлаживалась на каких-то тестовых примерах, не может выдержать реальной нагрузки и проблема кроется именно в том, что где-то глубоко внутри библиотеки, поставляемой с компилятором, не был реализован механизм блокировки доступа к разделяемому ресурсу. Кроме того, обычно переносимость программы с одного компилятора на другой уменьшает количество используемых возможностей языка программирования, потому что разные компиляторы, как это ни смешно звучит, по разному «соответствуют стандарту». Или, точнее, не соответствуют ему. А подобное ограничение на конструкции языка (одно из самых обидных лишений, конечно же, ограничение на использование шаблонов) сводит на нет большинство преимуществ C++.
В таких случаях выбор языка программирования C вместо C++ более предпочтителен, так как даст возможность изначально уменьшить количество непонятных проблем, возникающих в реальной эксплуатации программного продукта.
При этом стоит отметить потенциальную опасность C, который традиционно позволяет программисту делать все что угодно, зачастую пропуская его ошибки. Но эти ошибки выловить иногда значительно легче, чем объяснять различные странности, появляющиеся то тут, то там в программах на C++.
Более строго, можно сказать, что обычно к разрабатываемому программному обеспечению предъявляются какие-то требования, связанные с его качеством. Эти требования не могут быть настолько жесткими, чтобы совсем исключать вероятность наличия ошибок в программе, но чем они сильнее, тем лучше использовать старый и проверенный во многих разработках C. В остальных же проектах может быть обратная ситуация: сложность разработки на C вызовет увеличение сроков, связанное с отладкой и выявлением ошибок в коде у самих программистов. Но, повторюсь, подобные ошибки обнаружить проще, чем ошибки в компиляторе или стандартной библиотеке.
Резюме
Подводя итоги, хочется сказать что в последнее время я начал относиться с большой осторожностью к использованию С++ в проектах. Мне кажется, что должно пройти еще достаточно много времени, чтобы C++ достиг той устойчивости и стабильности в использовании, при которой он будет подходить по своим характеристикам для почти всех разработок, но до этой поры C остается вполне достойной альтернативой ему.
Что выбрать C++ или C#? С чего лучше начать?
Между собой оба языка очень похожи, при отсутствии опыта разобраться в различиях очень сложно. Статья поможет расставить всё по своим местам и укажет верный язык на основании поставленных задач.
Большинство программистов утверждают о необходимости начала изучения чистого C, но моё мнение – это пустая трата времени, которая не оправдается в будущем. Нет смысла изучать языки, которые уже давно устарели и были заменены на более перспективные, функциональные и интересные. Устаревшие языки не имеют нововведений, они практически не поддерживаются, а вакансии вовсе не появляются на различных биржах.
Единственная сфера использования – поддержание работоспособности проектов, которые ещё не перешли на обновлённые языки. Если проект качественный, он в скором времени обновится, иначе будет постепенно терять популярность, соответственно, все равно нет перспективы развития. При желании заняться изучением нового языка стоит предпочесть C++ или C# .
Особенности C#
После пропуска большого этапа «обучения» на Си , можно задаться вопросом куда же всё-таки направляться и какое состояние в сфере программирования на C# . При выборе этого языка стоит помнить, что программист строго привязан к операционной системе Windows, можно даже не учитывать преимущества Mono Develop, так как основной недостаток – полная зависимость от дальнейших действий Microsoft.
В большей части вакансии C# связанные с Asp.net – это веб разработка и всё тому подобное. Здесь уже выбор каждого. В отношении обучающего материала лучше сразу начинать с Шилдта, его способ описания ООП достаточно понятен и ясен, хотя и сам язык не вызывает особых сложностей, особенно если есть хоть какие-то знания. После его прочтения стоит перейти к Троелсену, который позволит почувствовать фундамент под ногами и даст более-менее приличные знания. После базового освоения языка можно дополнить информацию с помощью Рихтера, который детальнее раскроет особенности работы с .NET платформой.
Достоинства C++
Теперь стоит обратиться к изучению С++ , который хорошо показал себя за счёт абстракционного мышления. Иначе говоря, программист волен сам выбирать писать ли ему на высоком или низком уровне, изменяя способ написания в зависимости от задачи.
С++ уже позволяет писать программы, которые могут работать на разных платформах, с этой целью разработан Qt .
В отношении методичной литературы стоит посоветовать Страуструпа, его книга представлена в форме справочника, которая хорошо знакомит с принципами языка и методами работы. Когда с ним будет покончено можно перейти к Саттеру и Мейерсу, но для закрепления материала нужно обязательно использовать практические навыки. Этого уже достаточно для понимания языка выше среднего.
Не относится к теме статьи, но стоит также присмотреться к языку Java .
Если судить в целом, то все языки представляют собой только инструмент. Правильное использование – это залог успеха, состав мозгов и способ мышления помогают добиваться впечатляющих результатов всегда. Вовсе не обязательно изучать языки наизусть, напротив, заучивание даже плохо, достаточно всего лишь понимать принципы работы. Чтобы нам не углубляться в алгоритмы, стоит изучить книгу Кормена.
У каждого языка различаются сферы использования. Если акцент ставится на написание игр, лучше предпочесть С#, ведь язык применяется в основе распространённого движка Unity . Он позволяет создавать игры как с 2-мерной графикой, так и полноценные 3D. В противовес можно сказать, что С++ применяется в основе Unreal Engine , он отличается большей мощностью и требуется для написания масштабных игр для ПК.
Сравнение языков
1. Скорость написания
C# обеспечивает быстрейший старт в сфере программирования, прототип можно создать значительно быстрее. Если в приоритете лежит скорость изначальной разработки, стоит выбирать C#, который выигрывает у С++.
После создания инфраструктуры, подбора основных методов работы, подключения, изучения библиотек и настройки билда скорость приблизительно выравнивается, значительного преобладания на одном из языков не отмечается.
Вывод следующий, если цель стоит в создании небольшого проекта с малым бюджетом, стоит выбирать C#, так как это позволит сократить время и затраты. Для создания продолжительных, крупных проектов преимущество будет незначительным.
2. Кроссплатформенность
В отношении кросплатформенности С++ сильно превосходит конкурента, хотя и есть определённые оговорки. Придётся прибегнуть к дополнительным затратам и между некоторыми платформами отмечается бинарная несовместимость.
C# не кросплатформенный, существует разработанное решение со стороны на .net, оно позволяет связывать сразу несколько платформ. Изначально планировалось создание языка для кросплатформенного кодинга, но с течением времени направление развития было изменено.
Сейчас под Windows разработана достаточно полноценная инфраструктура на .net, а в остальных платформах такого решения не было запущено.
3. Библиотеки
Выбор между библиотеками можно сделать в пользу С++, так как не только их количество больше, но и ассортимент качественнее. За длительную историю разработки удалось достичь хорошей оптимизации и было устранено большее количество недочётов. Многие библиотеки находятся в открытом доступе, могут использоваться на разных платформах и имеют открытый код.
Даже с учётом ряда положительных сторон всё не настолько радужно, ведь многие библиотеки С++ разработаны по различным структурам, порой даже без них. Нередко встречается структурно-процедурная форма построения, причина такого недостатка – перенос библиотеки с Си.
Дополнительным минусом можно выделить формирование и переопределение основных типов данных. В множестве библиотек С++ возникает необходимость создавать собственные контейнеры, изменять базовые типы данных и строки. Со стороны логического обоснования – это обеспечивает повышенную производительность, улучшение кросплатформенности, устранение недостатков кода. Несмотря на очевидные позитивные стороны вопроса значительно снижается удобство пользования и красота кода.
Среди базовых библиотек C++ выбор не такой обширный, по функционалу С# превосходит их. Основная сложность и задача программиста – это правильный подбор библиотек и это потребуется даже при выполнении небольшого проекта.
4. Стоимость поддержки
Значительной разницы в цене поддержки между обоими языками не отмечается. Важно осознавать, что отдельные баги внутри приложений на С# сложно поддаются устранению методами .net. Если потребуется исправление багов, цена резко увеличится, а поддержание станет дороже. Если коснётся рефакторинга, то чаще всего проекты С# проще поддаются изменению.
Лично я не могу со 100% уверенностью всем советовать выбирать тот или иной язык, так как нет правильного ответа на вопрос. Выбор зависит от поставленных целей, типа задач и предполагаемого результата, который требуется достичь. Для меня С# значительно приятнее и ближе, ведь основная часть работы связана с движком Unity, но нельзя скрывать повышенную популярность Unreal Engine на C++.
После определения задачи стоит подобрать лучший язык на основании перечисленных пунктов, а также типа синтаксиса.
Больше интересных новостей
Алгоритмы и структуры данных: зачем они разработчику?
Краткая история программирования / С чего все начиналось
13 признаков, по которым вы можете стать успешным дизайнером
5 советов, как эффективно изучить Frontend
Что лучше c или c
Почитав Б.Страуструпа, Г.Буча и вообще книги об объектно-ориентированном программировании, некоторые приверженцы C делают вывод о том, что C++ — это нечто запредельно сложное и гиганский шаг вперед. Это заблуждение. На самом деле C++ — это тот же C, но с некоторыми удобными упрощениями. Если вы — хороший С-программист и воспринимаете C++ как нечто на порядок более крутое, то это — диагноз. Который называется «перечитал заумных книжек». Это излечимо J
Часто можно слышать споры на тему: писать на C или на C++? При этом существует расхожее мнение о том, что есть два стиля написания программ: стиль С и стиль C++. Они противопоставляются друг другу. C++ ассоциируется с ООП (объектно-ориентированноым программированием), а чистый C — с ПОП (процедурно-ориентированным программированием). ООП и ПОП также противопоставляются.
На самом деле, все, что есть нового в C++ — уже было в C и вы этим пользовались (если действительно много программировали на C). Только в C++ это записывается чуть по-другому. Однажды у меня вышел спор с одним из приверженцев C на эту тему, в результате чего был написан список из 10 различий между двумя языками.
Различие 1. Объекты
В C++ появились классы и объекты. Технически класс C++ — это тип структуры в C, а объект — переменная такого типа. Разница только в том, что в C++ есть еще модификаторы доступа и полями могут быть не только данные, но и функции (функции-методы).
Функция-метод — это обычная функция C, у которой первый параметр — это указатель на структуру, данные которой она обрабатывает: this. Если сравнить, как выглядят функции-методы в C++ и функции с параметром-указателем на структуру в C, то мы обнаружим, что всего лишь изменилась форма записи. В C++ получается короче, так как this и имя типа во многих случаях писать не обязательно (подразумевается по умолчанию).
Модификаторы доступа — это слова public, private и protected. В C вместо них была внимательность программиста: public — значит с этими полями делаю, что хочу; private — значит к этим полям обращаюсь только с помощью методов этой структуры; protected — то же, что public, но еще можно обращаться из методов унаследованных структур (см. следующий пункт).
Различие 2. Наследование
То, что в C++ — наследование, в C — это просто структура в структуре. При программировании в стиле C++ применяются такие красивые и звучные слова, как «класс Circle порожден от класса Point» или «класс Point наследуется от класса Circle и является производным от него». На практике все это словоблудие заключается в том, что структура Point — это первое поле структуры Circle.
При этом реальных усовершенствований два. Первое — поля Point считаются так же и полями Circle, в результате доступ к ним записывается короче, чем в C. Второе — в обоих структурах можно иметь функции-методы, у которых имена совпадают с точностью до имени структуры. Например, Point::paint и Circle::paint . Следствие — не надо изобретать имена вроде Point_paint и Circle_paint, как это было в C, а префиксы Point:: и Circle:: в большинстве случаев можно опускать.
Различие 3. new и delete
В C++ появились две новые операции: new и delete. В первую очередь это — сокращения для распространенных вызовов функций malloc и free:
Point *p = (Point*) malloc(sizeof(Point)); free(p);
Point *p = new Point; delete p;
При вызове new автоматически вызывается конструктор, а при вызове delete — деструктор (см. следующий пункт). Так что нововведение можно описать формулой: new = malloc + конструктор, delete = free + деструктор.
Различие 4. Конструкторы и деструкторы
Когда программируешь в стиле C, после того, как завел новую переменную типа структуры, часто надо ее инициализировать и об этом легко забыть. А перед тем как такая структура закончит свое существование, надо ее почистить, если там внутри есть ссылки на какие-то ресурсы. Опять-таки легко забыть.
В C++ появились функции, которые вызываются автоматически после создания переменной структуры (конструкторы) и перед ее уничтожением (деструкторы). Во всех остальных отношениях это — обычные функции, на которые наложен ряд ограничений. Некоторые из этих ограничений ничем не оправданы и мешают: например, конструктор нельзя вызвать напрямую (дестркутор, к счастью, можно). Нельзя вернуть из конструктора или деструктора значение. Что особенно неприятно для конструктора. А деструктору нельзя задать параметры.
Различие 5. Виртуальные функции
Из всех усовершенствований это вызывает наибольшую «щенячью радость». Как обычно, придуманы и звучно-научно-рекламные названия: «полиморфизм», «виртуальный», «абстрактный». Если отбросить разницу в терминологии, то что получим в сухом остатке? А получим мы очередное сокращение записи. И очень большое сокращение.
При программировании на C часто бывает так, что имеется несколько вариантов одной и той же структуры, для которых есть аналогичные функции. Например, есть структура, описывающая точку (Point) и структура, описывающая окружность (Circle). Для них обоих часто приходится выполнять операцию рисования (point). Так что, если у нас есть блок данных, где перемешаны точки, окружности и прочие графические примитивы, то перед нами стоит задача быстро вызвать для каждого из них свою функцию рисования.
Обычное решение — построить таблицу соответствия «вариант структуры — фукция». Затем берется очередной примитив, определяется его тип, и по таблице вызывается нужная функция. В C этот метод применять довольно нудно из-за того, что во-первых, надо строить эту таблицу, а во-вторых, внутри структур заводить поле, сигнализирующее о том, какого она типа, и следить за тем, чтобы это поле содержало правильное значение.
В C++ всем этим занимается компилятор: достаточно обозначить функцию-метод как virtual, и для всех одноименных функций будет создана таблица и поле типа, за которыми следить будет опять-таки компилятор. Вам останется только пользоваться ими: при попыке вызвать функцию с таким именем, будет вызвана одна из серии одноименных функций в зависимости от типа структуры.
Различие 6. Исключения
Исключение по своей сути — это просто последовательность goto и return. Основан на обычной C-технологии setjmp/longjmp. try и catch — это setjmp с проверкой. throw — это longjmp. Когда вызывается throw, то проверяется: если он окажется внутри блока try, то выполняется goto на парный блок catch. Если нет, то делается return и ищется catch на уровень выше и так далее.
Наличие в throw/catch параметра ничего принципиально не меняет: и в обычном C можно было заполнить какие-то переменные перед вызовом longjmp и потом их проанализировать.
Различие 7. Перегруженные операторы
Относитесь к ним как к уродливым функциям и все станет ясно. a + b, где a и b — типа Point это функция от двух аргументов a и b, возвращающая Point:
Point operator+(Point a, Point b)
Написать a+b равносильно вызову такой функции: operator+(a,b). Иногда эта технология удобна, а иногда вносит путаницу.
Различие 8. Ссылка
Многие программисты изучали C на основе языка Pascal. В Pascal есть возможность возвращать из функции больше одного параметра. Для этого применялось магическое слово «var». В C для того, чтобы сделать то же самое, приходилось расставлять в тексте уйму символов «*».
Разработчики C++ вняли стонам несчастных программистов и ввели слово var. А чтобы все это выглядел ооригинально, «var» они переименовали в «&» и назвали «ссылкой». Это вызвало большую путаницу, так как в C уже были понятия «указатель» (та самая звездочка) и «адрес» (обозначался тем же символом &), а понятие «ссылка» звучит тоже как что-то указующе-адресующее. Вот если бы, не мудрствуя лукаво, добавили слово var…
С одной стороны, использование ссылок намного сокращает текст программы. Но есть и неприятности. Во-первых, вызов функции, в которой параметр является ссылкой, выглядит так же, как вызов с обычным параметром. В результате «на глаз» незаметно, что параметр может измениться. А в C это заметно по значку &. Во-вторых, многочисленные звездочки в C напоминают программисту о том, что каждый раз выполняется дополнительная операция * разыменования указателя. Что побуждает сделать разумную оптимизацию. В C++ эти операции остаются незамеченными.
Различие 9. Inline, template и default-аргумент
Аргумент по-умолчанию — это то, о чем мечтали программисты C: чтобы иногда не надо было при вызове задавать некоторые параметры, которые в этом случае должны иметь некоторое «обычное» значение.
Желание программистов C контролировать типы параметров в define-ах породило в C++ inline-функции. Такая функция — это обычный define с параметрами, только не надо мучиться с символами «\» и проверяются типы.
Желание узаконить в параметрах define имя типа породило template. Главный плюс template — то, что #define с одинаковыми параметрами породит два одинаковых куска кода. А template в компиляторе скорее всего будет соптимизирован: одинаковые куски кода будут соединены в один. Имеется небольшой контроль типов по сравнению с #define, но не очень удобный.
В то же время template имеют ряд серьезных недостатков. Первый — ужасный, неудобный синтаксис. Чтобы это ощутить, достаточно попробовать. Уж лучше бы разрешили не контролировать типы некоторых параметров inline-функций. Второй недостаток — template остался так же неудобен при работе с отладчиком, как и #define.
Ну и последнее нововведение, продиктованное, видимо, все тем же стремлением избавиться от #define. Это — тип «имя поля» (pointer to member). В C удобно было применять имена полей структур в define. В C++ тоже самое можно сделать с помощью операторов ::*, .* и ->*. Например &Circle::radius — это имя поля radius структуры Circle, а Circle::*radius — соответствующий тип. Такую величину можно передать, как параметр. Фактически речь идет о смещении этого поля относительно начала структуры. Бывает полезно. Примерно так же можно передать адрес функции-метода.
Различие 10. Язык более высокого уровня?
Когда появились все эти нововведения, то многим стало видно то, что раньше было видно не столь многим. Это нормально: код упростился, а значит те его свойства, которые раньше были замаскированы лишними символами, стали заметны при меньшем напряжении мозгов. В этом и только в этом заключается более высокий уровень C++. Чуть больше абстракции, чуть меньше деталей — можно сосредоточится на более крупных блоках.
Существует мнение, что писать в стиле C на C++ — дурной стиль. Это мнение — всего лишь дань моде. Если в стиле C++ получается короче, лучше, надежнее, то глупо писать в стиле C. Это так, но верно и обратное!
Простой пример: у вас есть большой массив из 100 тысяч структур Point, который инициализируется один раз (все поля на 0) и много раз копируется в такие же массивы. Писать для элемента такого массива конструктор оказывается накладно. При его создании будет вызван конструктор для каждого элемента. Потом вы создадите массив, куда его надо копировать — и снова вызовы конструкторов. Затем вы выполняете копирование и затираете результаты второй инициализации. Мало того, что 100 тысяч вызовов конструктора просто не сопоставимы с одним вызовом memset, но эта серия вызовов будет повторяться не один раз, а много.
Такие примеры можно привести для каждого нововведения C++. Каждый плюс неизбежно тянет за собой минусы. Для хорошего программиста главным законом должна быть не мода, а конечный результат и трезвый расчет: что в данном конкретном случае выгоднее с точки зрения эффективности программы и времени, затраченного на ее разработку.
Что касается объектно-ориентированного программирования, то на самом деле оно не имеет никакого отношения к разнице между C и C++. Благодаря ряду усовершенствований, код на C++ компактнее и надежнее, чем на C. Часть этих усовершенствований связана с ООП, а часть — нет. Например, аргументы функций по-умолчанию и inline-функции к ООП не имеют никакого отношения. Они имеют отношение к ужесточению контроля типов.
ООП — это просто идея: «в зависимости от данных, выполнить процедуру». А ПОП (процедурно ориентированное программирование) — «в зависимости от процедуры изменить данные». Глупо молиться на ООП или на ПОП или отвергать что-то из них и тем более ужасаться при их смешивании. Разумно использовать тот и другое, смотря как будет точнее, проще, быстрее, компактнее.
Смешон консерватор, который говорит: «Я назло не буду использовать ООП, так как это — глупая новомодная штучка.» Такой консерватор обычно упрямо применяет только C и при этом не замечает, что давно пишет в стиле ООП, но на чистом C! Он думает, что раз он использует C, его никто не заподозрит в излишнем умничаньи.
Смешон модник, который говорит: «Я буду использовать ООП везде, так как хочу прослыть прогрессивным человеком, который быстро осваивает все новое!» Такой «передовик» упрямо применяет классы и template где надо и где не надо. Он громогласно вопит об ООП, но сколько-нибудь сложная часть его кода обычно написана в стиле ПОП: потому, что он ценит ООП только как признак прогрессивности, но не понимает простого смысла, заключенного в нем.
«Будьте проще и люди к вам потянутся!» J
Чем отличается C от C++
Короткий ответ: C++ — это улучшенный C. У этих языков одинаковый на 99% синтаксис и команды, но C — это больше про структурное и процедурное программирование, а C++ — про объектно ориентированное.
C — язык, который сделал в 1973 году Деннис Ритчи. Главная цель языка — скорость, быстродействие и универсальность. Язык изначально проектировался как системный, чтобы на нём можно было писать код для процессоров, драйверов и создавать на нём операционные системы. В то время большинство этих вещей делали на ассемблере, и Ритчи хотел это упростить.
C++ придумал Бьёрн Страуструп в начале восьмидесятых, когда ему не хватало возможностей стандартного C. Он сделал язык более строгим, добавил в него классы, ООП-подход и перегрузку операторов, сохранив скорость оригинального С. В 1983 году Бьёрн переименовал язык из «C с классами» в C++.
�� О перегрузке операторов как-нибудь в другой раз 🙂
| C | C++ |
Код читается проще
Проще портировать код на другие платформы
Есть структуры и переменные типа «структура»
Наследование — это структура внутри структуры
void — обязательное слово
Можно объявлять глобальную переменную несколько раз
Исключения нужно конструировать самому
Нет перегрузки операторов
Почти всё стандартно и предсказуемо
Для чего изучать
C — классический язык разработки системного ПО и любого софта для микропроцессоров. На нём написаны Linux, большая часть Windows и MacOS. Если взять любой современный носимый гаджет или электронное устройство, в большинстве случаев они работают тоже под управлением программы на C. В мире огромное количество кода, который написан на C (и ещё столько же будет написано), поэтому проблем с работой у C-программистов не предвидится.
C++ — выбор тех, кому одновременно нужна вся мощь C и гибкость объектно ориентированного программирования. Counter-Strike, StarCraft и World of Warcraft написаны на C++, а это значит, что можно сочетать производительность C и современные технологии. Часть движка Unity тоже написана на C++, чтобы получить прямой доступ к памяти и ресурсам системы.
Нельзя ли подробнее?
На самом деле нет такой уж большой разницы между C и C++. Это одинаково мощные и быстрые языки, просто у них разная область применения и стиль программирования.
Если вам важна скорость, производительность и относительная простота языка — смотрите на C, там это всё есть. С другой стороны, из-за простоты в нём многие вещи придётся делать вручную — обрабатывать исключения, следить за сроком жизни переменных и структур или писать дополнительный код.
Сторонникам ООП больше подойдёт C++ — в нём уже есть всё, что нужно для работы с объектами, областями видимости и прочим добром. Иногда такой код сложнее поддерживать и он может работать на несколько процентов медленнее, чем на C, но в нём есть та свобода, которой нет в оригинальном языке. Та же перегрузка операторов — удивительно мощная вещь в умелых руках, которая может сэкономить много времени и ресурсов.
Чтобы было понятнее, скоро напишем подробно про оба языка. А вы не болейте и берегите себя.
Получите ИТ-профессию
В «Яндекс Практикуме» можно стать разработчиком, тестировщиком, аналитиком и менеджером цифровых продуктов. Первая часть обучения всегда бесплатная, чтобы попробовать и найти то, что вам по душе. Дальше — программы трудоустройства.