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

Точка с запятой в С++?

Действительно ли требуется ошибка "с точкой с запятой"? Почему бы не рассматривать это как предупреждение?

Когда я компилирую этот код

int f = 1
int h=2;

компилятор разумно сообщает мне, где я его не хватает. Но мне это нравится: "Если вы это знаете, просто относитесь к нему так, как если бы он был там, и вперед. (Позже я могу исправить предупреждение.)

  int sdf = 1, df=2;
  sdf=1 df =2

Даже для этого кода он ведет себя одинаково. То есть, даже если несколько операторов (без;) находятся в одной строке, компилятор знает.

Итак, почему бы просто не удалить это требование? Почему бы не вести себя как Python, Visual Basic, и т.д.

Резюме обсуждения

Два примера/экземпляры отсутствовали, а полуколония действительно вызовет проблему.

1.

return
 (a+b)

Это было представлено как один из худших аспектов JavaScript. Но в этом случае вставка с запятой является проблемой для JavaScript, но не для С++. В С++ вы получите еще одну ошибку, если вставка ; будет выполнена после возврата. То есть отсутствует возвращаемое значение.

2

int *y;
int f = 1
*y = 2;

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

4b9b3361

Ответ 1

Существует много случаев, когда требуется точка с запятой.

Что делать, если:

int *y;
int f = 1
*y = 2;

Это будет проанализировано как

int *y;
int f = 1 * y = 2;

Таким образом, без точек с запятой это двусмысленно.

Ответ 2

Очень хорошо, что компилятор С++ этого не делает. Одним из худших аспектов JavaScript является вставка точки с запятой. Представьте это:

return
  (a + b);

Компилятор С++ с радостью продолжит работу на следующей строке, как ожидалось, а язык, который "вставляет" точки с запятой, например JavaScript, будет относиться к нему как к "возврату"; и пропустите "(a + b)".

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

Ответ 3

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

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

Ответ 4

; для удобства программиста. Если строка кода очень длинная, мы можем нажать Enter и перейти ко второй строке, потому что у нас есть ; для разделителя строк. Это программные соглашения. Должен быть разделитель строк.

Ответ 5

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

Но, вопреки тому, что говорили другие люди, ни одна форма разделителей (как абсолютная) не является строго необходимой.

Рассмотрим, например, Haskell, который тоже не имеет. Даже текущая версия VB допускает разрывы строк во многих местах внутри оператора, как и Python. Во многих местах не требуется продолжения строк.

Например, теперь VB позволяет использовать следующий код:

Dim result = From element in collection
             Where element < threshold
             Select element

Нет разделителей инструкций, никаких строк и, тем не менее, никаких двусмысленностей.

Теоретически это можно было бы сделать гораздо дальше. Все неоднозначности могут быть устранены (опять же, посмотрите на Haskell), введя некоторые правила. Но опять же, это значительно усложняет синтаксический анализ (он должен быть чувствительным к контексту во многих местах, например, вашим примером return, который не может быть разрешен без предварительного указания типа возврата функции). И снова это значительно усложняет вывод осмысленной диагностики, поскольку ошибочный разрыв строки может означать любую из нескольких вещей, поэтому компилятор не может знать, какую ошибку сделал пользователь, и даже там, где была сделана ошибка.

Ответ 6

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

Ответ 7

+1 для вас обоих.

Полу-двоеточие - это разделитель командной строки, в отличие от VB, python и т.д. C и С++ игнорируют пробел в строках кода, включая возврат каретки! Это было изначально потому, что на начальном этапе компьютерные мониторы C могли справляться только с 80 символами текста, а поскольку С++ основывался на спецификации C, он следовал примеру.

Я могу опубликовать вопрос "Почему я должен продолжать получать ошибки об отсутствующих символах в VB, когда я пытаюсь писать код по нескольким строкам, конечно, если VB знает о проблеме, которую он может вставить?"

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

Ответ 8

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

Меня больше беспокоит предложение компилятора исправить код.

Если вы когда-либо видели чудесный инструмент (например,... hum let pick a merge tool) и способ его автоматической работы, вы были бы очень рады, что компилятор не изменил код, В конечном счете, если компилятор знал, как исправить код, тогда это будет означать, что он знал ваши намерения, и мысль о передаче еще не реализована.

Что касается предупреждения? Любой программист, заслуживающий своей соли, знает, что предупреждения следует рассматривать как ошибки (и компиляция остановлена), так что было бы преимуществом?

Ответ 9

int sdf = 1,df=2;
sdf=1 df =2

Я думаю, что общая проблема заключается в том, что без точки с запятой нет ничего общего с тем, что мог бы сказать программист (например, вторая строка была предназначена как sdf = 1 + df - 2; с серьезными опечатками). Что-то вроде этого вполне может возникнуть из-за полностью произвольных опечаток и иметь какое-либо намеченное значение, поэтому, возможно, это не такая хорошая идея, чтобы заставить компилятор молча "исправлять" ошибки.

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

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

Кроме того, предупреждения, а не ошибки компилятора слишком слабы. Люди компилируют код с предупреждениями, игнорируют предупреждения, которые они получают, и AFAIK в стандарте никогда не предписывает то, о чем должен предупредить компилятор.