Почему C ++ все еще «гибрид»

По смежному вопросу выяснилось, почему C ++ не совместим с C во многих аспектах. Однако C ++ по-прежнему является «гибридным» * языком. И, к сожалению, многие программисты все еще рассматривают C ++ как «C с потоками и встроенными строками». В результате получается действительно плохо написанный код, который не является ни C ++, ни C. ИМХО, было бы лучше, если бы язык / компилятор заставлял программистов до некоторой степени писать более элегантный код. Так есть ли смысл поддерживать гибрид C ++ (например, C ++ 0x и будущие версии)?

_{* Под гибридом я подразумеваю, что программист должен решить, будет ли он / она использовать: стандартные строки и потоки, классы, пространства имен, отличные от заданных по умолчанию, и т. Д.}

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

ИМХО, было бы лучше, если бы язык / компилятор заставлял программистов до некоторой степени писать более элегантный код.

Нет, не будет. Совсем. В качестве тривиальной демонстрации того, почему, определите элегантность, и тогда я держу пари, что десять человек не согласятся с вами.

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

Примечательно, что стандартные строковые и потоковые классы фактически сосут . std::stringне имеет поддержки Unicode и худшего раздутого интерфейса, который вы только можете себе представить. Потоки имеют ужасные накладные расходы и плохой дизайн, даже прибегая к виртуальному наследованию, и указатели на функции, const char*и тому подобное. Я бы не стал никого наказывать за полную замену обоих этих классов / групп классов на собственные.

Отказ от использования классов и пространств имен - это нормально для кода в виде доски, и существует множество библиотек, которые предоставляют функции, не входящие в класс. Принудительный класс - действительно плохая идея.

C ++ является гибридом не потому, что позволяет писать код в стиле C, а потому, что он поддерживает несколько парадигм программирования, таких как процедурный, объектно-ориентированный и универсальный. C ++ не заставляет вас делать что-то одно, и в этом его сила, потому что разные проблемы легче решать с помощью разных парадигм.

ИМХО, было бы лучше, если бы язык / компилятор заставлял программистов до некоторой степени писать более элегантный код.

Затем вы должны сначала определить, что значит элегантный . Тогда вам нужно будет проверить, подходит ли ваше определение элегантности всем проблемным областям и платформам, для которых используется C ++. Стиль кодирования, элегантный для написания текстового процессора для Windows, может полностью не подходить для написания встроенной системы.

Подумайте о написании кода C ++ для запуска на DSP. Во-первых, компилятор C ++ для этого DSP может просто не поддерживать определенные функции C ++, такие как потоки. Во-вторых, вы сильно ограничены скоростью процессора и, возможно, памятью, поэтому некоторые функции C ++ могут просто снизить производительность. Например, вам, возможно, придется избегать виртуальных функций ради скорости. Такие соображения радикально изменили бы ваш стиль программирования по сравнению с тем, что вы бы использовали на ПК, и C ++ позволяет это.

Подводя итог, C ++ - это огромный и сложный язык с множеством функций. Существует множество причин, по которым любое подмножество этих функций может быть неприменимо к конкретному проекту: скорость, переносимость, поддержка компилятора или даже опыт и знакомство программиста. По этой причине использование языка заставляет разработчика использовать определенные функции в отличие от других для какой-либо задачи - плохая идея. Подумайте о Java, где язык требует, чтобы каждая функция была методом класса. Есть очень много случаев, когда создание класса просто для переноса метода является неловким и ненужным, и все же вы должны сделать это, потому что язык заставляет вас делать это.

ИМХО, было бы лучше, если бы язык / компилятор заставлял программистов до некоторой степени писать более элегантный код.

Никто не заставляет кого-либо использовать C ++ в первую очередь. Если язык вам не подходит, используйте другой - существует много языков, обозначенных как «C ++ без C».

Философия дизайна C ++ - позволить программисту решать. Если они хотят выстрелить себе в ногу, то пусть. Это позволяет делать много плохих вещей, но также дает большую гибкость. Например, маловероятно, что Boost мог бы быть написан на языке, подобном Java, поскольку он использует преимущества языковых функций и практик, которые обычно избегают. Также маловероятно, что C ++ станет таким же большим, как сегодня - доступ к обширной библиотеке C - огромный плюс, принимайте его или оставляйте.

Совместимость C ++ с C, безусловно, является одним из его слабых мест, но имейте в виду, что это один из самых больших.

Я собираюсь добавить замечательную цитату Джона Перди, которая, на мой взгляд, чрезвычайно актуальна:

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

Удаление гибрида может улучшить элегантность, но это препятствует способности.

Если бы комитет попытался заставить людей использовать (чье-то представление) более изящный язык, он, вероятно, был бы проигнорирован. Люди будут продолжать делать то, что они хотят, и поставщики компиляторов будут следовать за рынком (но поставщики компиляторов имеют достаточное представительство в комитете, чтобы предотвратить это).

Многое из того, что вы защищаете, на самом деле зависит от суждения, так или иначе основанного на проблемной области. Существует множество небольших программ, которым просто не нужны (для одного примера) пространства имен. Попытка заставить меня использовать пространство имен при написании 30-строчного текстового фильтра была бы глупой и высокомерной. Даже если вы решили, что это применимо только тогда, когда задействовано более X строк кода, или функций Y, или чего бы то ни было, это все равно будет контрпродуктивным. Пространства имен были разработаны по причине, чтобы предотвратить / вылечить определенные проблемы. Попытка навязать их использование в отсутствие этих проблем ни к чему не приводит.

В то же время, я думаю, что стоит отметить, что довольно много людей действительно тратят много времени и усилий, пытаясь не только включить элегантность в C ++, но и научить людей использовать эти возможности для написания лучшего кода (например, многие участники Boost). Таким образом, люди, которые продолжают настаивать на написании своего кода как «C с классами», в значительной степени игнорируют то, что там есть. Я думаю, что им будет так же удобно игнорировать новые компиляторы, как и все, что узнали о том, как использовать C ++ за последнее десятилетие или более (например, Modern C ++ Design был опубликован 11 лет назад, но большинство людей Вы говорите, по-видимому, еще не слышали об этом, тем более читали или понимали даже его самые простые части).

Ваша идея составляет большую часть обоснования дизайна Java. Java заставляет вас использовать классы, организовывать файловую иерархию в соответствии с иерархией пакетов, перехватывать исключения и т. Д. Людям все еще удается писать в нем C-подобный код.

Как программисты, мы иногда забываем, что лучшее решение может быть не техническим. Рецензии являются наиболее известным решением в этом случае.

С ++ не имеет «единственно верного пути»; У каждого подхода есть свои сильные и слабые стороны. Решение может быть написано сотней разных способов.

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

Я думаю, тот факт, что все перечисленные вами вещи являются необязательными, создает потенциал для большей элегантности, а не уменьшения. Излишне используемая функция в моих глазах не элегантна.

Проблемы, которые нам нужно решить с помощью программирования, очень разные.
Некоторые из них хорошо решаются с использованием ОО-принципов (например, GUI), некоторые лучше поддаются чисто функциональной обработке (например, числовые данные), а некоторые лучше всего выражаются на низкоуровневом языке «близко к кремнию».

Множество программного обеспечения должно решать подзадачи, которые решаются наилучшим образом любым из этих способов. Принуждение решения к определенной форме приведет только к коду, который менее соответствует его назначению (вы можете даже сказать «менее элегантный»).

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