В глубине души проблема заключается в том, что исправление ошибок затруднительно, независимо от контекста.
И когда вы учитываете ужасные грамматики C и C ++, вы можете только удивляться, что сообщения об ошибках не хуже этого!Я боюсь, что грамматика C была разработана людьми, которые не имели понятия о существенных свойствах грамматики, одним из которых является то, что чем меньше зависимость от контекста, тем лучше, а другим - то, что вы должны стремиться сделатьэто настолько однозначно, насколько это возможно.
Давайте проиллюстрируем распространенную ошибку: забыть точку с запятой.
struct CType {
int a;
char b;
}
foo
bar() { /**/ }
Хорошо, так что это не так, куда должна идти пропущенная точка с запятой?Ну, к сожалению, это неоднозначно, оно может идти до или после foo, потому что:
- C считает нормальным объявление переменной с шага после определения
struct - C считаетНормально не указывать тип возвращаемого значения для функции (в этом случае значение по умолчанию равно
int)
Если мы рассуждаем, мы можем видеть, что:
- если
foo называет тип, то он принадлежит объявлению функции - , если нет, он, вероятно, обозначает переменную ... если, конечно, мы не сделали опечатку, и она должна была быть написана
fool,это тип: /
Как видите, восстановление после ошибок очень сложно, потому что нам нужно сделать вывод, что имел в виду автор, а грамматика далека от восприимчивости.Это не является невозможным, и большинство ошибок действительно может быть диагностировано более или менее правильно, и даже может быть исправлено ... просто требуется значительных усилий.
Кажется, что люди, работающие над gcc больше заинтересованы в создании быстрого кода (и я имею в виду быстро, поиск последних тестов в gcc 4.6) и добавлении интересных функций (gcc уже реализует большинство - если не все - C ++ 0x)чем производить легко читаемые сообщения об ошибках.Можете ли вы их винить?Я не могу.
К счастью, есть люди, которые считают, что точные отчеты об ошибках и их исправление - очень достойная цель, и некоторые из них уже довольно долго работают над CLang и продолжаютсделайте так.
Некоторые приятные функции, в верхней части моей головы:
- Краткие, но полные сообщения об ошибках, которые включают исходные диапазоны, чтобы точно указать, откуда произошла ошибка
- Fix-It замечает, когда становится очевидным, что имелось в виду
- В этом случае компилятор анализирует остальную часть файла, как если бы исправление уже было там, вместо выписывания строкна строчках
- (недавние) избегайте включения стека включения для заметок, чтобы вырезать излишне
- (недавние), пытаясь раскрыть только те типы параметров шаблона, которые фактически написал разработчик,и сохранение typedefs (таким образом, речь идет о
std::vector<Name> вместо std::vector<std::basic_string<char, std::allocator<char>>, std::allocator<std::basic_string<char, std::allocator<char>> >, который имеет все значение) - (в последнее время) корректно восстанавливается в случаеотсутствует
template в случае его отсутствия при вызове метода шаблона из другого метода шаблона
Но для каждого из них требуется от нескольких часов до дней работы.
Они, конечно, не пришли бесплатно.
Теперь концепции должны (как правило) сделать нашу жизнь проще.Но они были в основном непроверенными, и поэтому было сочтено предпочтительным удалить их из проекта.Я должен сказать, что рад этому.Учитывая относительную инерцию C ++, лучше не включать функции, которые не были полностью пересмотрены, и концептуальные карты меня не очень порадовали.Похоже, они не восхищались Бьярном или Хербом, поскольку говорили, что будут переосмысливать Концепции с нуля для следующего стандарта.