Подтвердить что ты не робот

Что может сделать С++ слишком жестко или беспорядочно на любом другом языке?

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

Меня особенно интересуют аспекты С++, которые мало известны или недостаточно используются.

Изменить: Люди, пожалуйста, по крайней мере, бегло читайте другие ответы, чтобы убедиться, что вы не дублируете сказанное, если вы согласны с тем, что кто-то сказал, повысьте его!

4b9b3361

Ответ 1

Я остался с С++, поскольку он по-прежнему является самым высокопроизводительным языком общего назначения для приложений, которые должны сочетать эффективность и сложность. В качестве примера я пишу программное обеспечение для моделирования поверхности в реальном времени для ручных устройств для геодезической промышленности. Учитывая ограниченные ресурсы, Java, С# и т.д. Просто не обеспечивают необходимых характеристик производительности, тогда как языки нижнего уровня, такие как C, развиваются гораздо медленнее, учитывая более слабые характеристики абстракции. Диапазон уровней абстракции, доступных разработчику С++, огромен, с одной стороны я могу перегрузить арифметические операторы, чтобы я мог сказать что-то вроде MaterialVolume = DesignSurface - GroundSurface, в то же время запуская несколько разных кучек для управления памятью наиболее эффективно для моего приложения на определенном устройстве. Объедините это с богатством свободно доступного источника для решения практически любой общей проблемы, и у вас есть чертовски мощный язык разработки.

Является ли С++ еще оптимальным решением для решения большинства проблем в большинстве доменов? Наверное, нет, хотя и в крайнем случае он все еще может использоваться для большинства из них. Является ли это еще лучшим решением для эффективной разработки высокопроизводительных приложений? ИМХО, без сомнения.

Ответ 2

RAII/детерминированная финализация. Нет, сбор мусора не так хорош, когда вы имеете дело с дефицитным, общим ресурсом.

Необработанный доступ к API OS.

Ответ 3

Стрельба в ногу.

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

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

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

Мой ответ был основан на многолетнем опыте стрельбы в ногу. По крайней мере, С++ позволяет мне делать это элегантно.

Ответ 4

Детерминированное уничтожение объекта приводит к некоторым великолепным шаблонам дизайна. Например, хотя RAII не является общей методикой сбора мусора, это приводит к некоторым впечатляющим возможностям, которые вы не можете получить с GC.

С++ также уникален тем, что имеет препроцессор с полным набором параметров Turing. Это позволяет вам (как в противоположность отложить) много задач кода компилировать время вместо времени выполнения. Например, в реальном коде у вас может быть утверждение assert() для проверки того, что никогда не произойдет. Реальность такова, что это произойдет рано или поздно... и произойдет в 3 часа ночи, когда вы в отпуске. Утверждение препроцессора С++ делает тот же тест во время компиляции. Время компиляции заканчивается с 8:00 до 17:00, когда вы сидите перед компьютером, наблюдая за сборкой кода; время ожидания утверждает, что неудача в 3:00 утра, когда вы спите на Гавайях. Это довольно легко увидеть победу там.

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

Ответ 5

Напишите встроенную сборку (MMX, SSE и т.д.).

Детерминированное уничтожение объекта. То есть реальных деструкторов. Легче управлять ограниченными ресурсами. Позволяет RAII.

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

Множественное наследование. Не все может быть сделано с интерфейсами. Иногда вы также хотите наследовать фактическую функциональность.

Ответ 6

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

Ответ 7

Шаблоны mixins обеспечивают повторное использование, которое я еще не видел в другом месте. С их помощью вы можете создать большой объект с большим количеством поведения, как будто вы все это писали вручную. Но все эти небольшие аспекты его функциональности можно повторно использовать, особенно отлично для реализации частей интерфейса (или всего этого), где вы реализуете несколько интерфейсов. Получаемый объект молниеносно, потому что он все вложен.

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

Ответ 8

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

(Хорошо, вы можете сделать это в C, сборке и, возможно, в Fortran, но С++ позволяет писать остальную часть вашей программы на более высоком уровне.)

Ответ 9

Это, вероятно, не будет популярным ответом, но я думаю, что отличные от С++ возможности его компиляции, например, шаблоны и #define. Вы можете делать всевозможные манипуляции с текстом в своей программе, используя эти функции, большая часть которых была оставлена ​​на более поздних языках во имя простоты. Для меня этот путь более важен, чем любой низкоуровневый бит, который, возможно, проще или быстрее в С++.

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

Объект "generics" в С# также ограничен по сравнению с шаблонами С++. С++ позволяет применять оператор точки к типу шаблона T слепо, вызывая (например) методы, которые могут не существовать, а проверки для правильности применяются только после фактического применения шаблона к определенному классу. Когда это произойдет, если все допущения, сделанные вами в отношении T фактически, будут сохранены, тогда ваш код будет скомпилирован. С# не допускает этого... тип "Т" в основном должен рассматриваться как объект, т.е. Использовать только самый низкий общий знаменатель операций, доступных для всего (назначение, GetHashCode(), Equals()).

С# покончил с препроцессором и реальными генериками во имя простоты. К сожалению, когда я использую С#, я нахожусь в поиске заменителей этих С++-конструкций, которые неизбежно более раздуты и многослойны, чем подход С++. Например, я видел, как программисты работают вокруг отсутствия #include несколькими раздутыми способами: динамическая привязка к внешним сборкам, переопределение констант в нескольких местах (один файл для каждого проекта) или выбор констант из базы данных и т.д.

Как сказала однажды мисс Крабапл из The Simpson, это "довольно хромой, Милхаус".

В терминах Computer Science эти функции времени компиляции С++ включают такие функции, как передача параметров по имени, которая, как известно, более мощна, чем вызов по значению и вызов по ссылке.

Опять же, это, возможно, не самый популярный ответ - любой вводный текст на С++ предупредит вас о #define, например. Но, работая с самыми разными языками на протяжении многих лет, и, учитывая теорию всего этого, я думаю, что многие люди плохо относятся к советам. Это особенно характерно для разведенного подполя, известного как "ИТ".

Ответ 10

Технически, я думаю, что нет, действительно!

Я, честно говоря, не думаю, что что-нибудь, что С++ может сделать, что Язык D не может. Независимо от того, какова способность С++, она всегда сложнее и грязнее, чем D или любой другой язык. Даже простая вещь, такая как декларация класса, намного сложнее и беспощаднее на С++, чем на любом другом языке.

Единственное, что может сделать С++, - это совместимость с миллионами строк кодов, уже написанных на С++.
Это единственное, что не может сделать ни один язык, кроме С++:)

Ответ 11

С# и Java заставляют вас использовать функцию main() в классе. Я нахожу это странным, потому что это разбавляет смысл класса.

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

К счастью, в отличие от С# и Java, С++ позволяет глобальные функции. Это позволяет использовать функцию main() снаружи. Поэтому С++ предлагает более простую, более последовательную и, возможно, более точную реализацию объектно-ориентированной идиомы. Следовательно, это одно, что может сделать С++, но С# и Java не могут.

Ответ 12

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

Ответ 13

Я думаю, что перегрузка оператора - довольно приятная функция. Конечно, его можно очень злоупотреблять (например, в Boost lambda).

Ответ 14

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

Ответ 15

С++ обеспечивает полный контроль над памятью и, как результат, делает поток выполнения программы намного более предсказуемым. Вы не только можете сказать точно, в какое время будут выполняться распределения и освобождения памяти, вы можете определить свои собственные кучи, иметь многократные кучи для разных целей и точно указать, где именно распределяются данные памяти. Это часто полезно при программировании встроенных/систем реального времени, таких как игровые консоли, сотовые телефоны, mp3-плееры и т.д., Которые:

  • имеют строгие верхние пределы в памяти, которые легко достичь (в отличие от ПК, который становится медленнее, когда у вас заканчивается физическая память)
  • часто имеют не однородную структуру памяти. Вы можете выделить объекты одного типа в одном куске физической памяти и объекты другого типа в другой части.
  • имеют ограничения программирования в реальном времени. Неожиданно вызывать сборщик мусора в неподходящее время может быть катастрофическим.

AFAIK, C и С++ - единственный разумный вариант для такого рода вещей.

Ответ 16

Хорошо, если честно, вы можете сделать что угодно, если вы готовы написать достаточно кода.

Итак, чтобы ответить на ваш вопрос, нет, вы ничего не можете сделать на другом языке, который С++ не может сделать. Это просто, сколько терпения у вас есть, и готовы ли вы посвятить долгие бессонные ночи, чтобы заставить его работать?

Есть вещи, которые упрощают выполнение оболочек С++ (потому что они могут читать файлы заголовков), например Office. Но опять же, это потому, что кто-то написал много кода, чтобы "обернуть" его для вас в RCW или "Runtime Callable Wrapper"

EDIT: вы также понимаете, что это загруженный вопрос.