Насколько важно соблюдение стандартов?

Для языка, такого как С++, существование стандарта является обязательным. И хорошие компиляторы стараются изо всех сил (ну, по крайней мере, большинство хороших компиляторов). Многие компиляторы имеют языковые расширения, некоторые из которых разрешены стандартом, некоторые из которых не являются. Из последнего вида 2 примера:

  • gcc typeof

  • microsoft-компиляторы разрешают чистому объявлению виртуальной функции иметь как чисто-спецификатор (= 0), так и определение (которое запрещено стандартом - не обсуждать почему, этот другой вопрос:)

(есть много других примеров)

Оба примера полезны в следующем смысле: example1 - очень полезная функция, которая будет доступна в С++ 0x под другим именем. example2 также полезен, и Microsoft решила не соблюдать запрет, который не имеет никакого смысла.

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

Я хочу, чтобы все правильно поняли мой вопрос. Это БОЛЬШАЯ вещь, которую MSVC допускает example2, и мне очень хотелось бы, чтобы эта функция была в стандарте. Он не нарушает совместимый код, он ничего не делает. Это просто не стандарт.

Вы хотите, чтобы этот файл отключил Microsoft2 при отключении языковых расширений в значение true? Обратите внимание, что слова microsoft, example2 и т.д. Являются заполнителями:) Почему?

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

ОТВЕТЫ

Ответ 1

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

  • Портирование из одной версии компилятора в другую. Я однажды должен был разместить приложение с 1,2 млн. LOC с VC6 на VC9. VC6 был известен тем, что был ужасно несовместимым, даже когда он был новым. Он допускал несовместимый код даже на самых высоких уровнях предупреждения, которые новый компилятор отклонил на самом низком уровне. Если код был написан более уступчивым образом, в первую очередь, этот проект не должен (не должен) занимать 3 месяца.

  • Портирование с одной платформы на другую. Как вы говорите, у современных компиляторов MS есть языковые расширения. Некоторые из них совместно используются компиляторами на других платформах, некоторые - нет. Даже если они разделены, поведение может быть несколько иным. Написание совместимого кода, а использование этих расширений делает ваш код правильным из слова go. "Портирование" просто тянет дерево вниз и делает перестройку, а не копает в недрах вашего приложения, пытаясь понять, почему 3 бита неправильны.

  • С++ определяется стандартом. Расширения, используемые компиляторами, меняют язык. Новые программисты, выходящие в сети, которые знают С++, но не диалект, используемый вашим компилятором, будут быстрее ускоряться, если вы напишете на Standard С++, а не на диалект, который поддерживает ваш компилятор.

Ответ 2

Сначала ответьте на несколько комментариев. Соответствующее расширение MS VC выглядит следующим образом:

struct extension { 
    virtual void func() = 0  { /* function body here */ }
};

Стандарт позволяет реализовать чистую виртуальную функцию, но не "на месте", как это, поэтому вам нужно написать что-то вроде этого:

struct standard { 
    virtual void func() = 0;
};

void standard::func() { ; }

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

По крайней мере, IMO, единственный ответ на этот вопрос касается людей, которые заботятся о переносимости, чтобы иметь (и использовать) по крайней мере пару компиляторов на регулярной основе. Для С++ один из них должен основываться на интерфейсе EDG; Я считаю, что он имеет значительно лучшее соответствие, чем большинство других. Если вы используете компилятор Intel на регулярной основе в любом случае, это прекрасно. В противном случае я бы рекомендовал получить копию Comeau С++; это всего лишь $50, и это самое близкое к доступной ссылке. Вы также можете использовать Комо онлайн, но если вы используете его на регулярной основе, стоит получить собственную копию.

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

Изменить: если посмотреть на это снова, некоторые советы выглядят довольно устаревшими, особенно рекомендация для EDG/Comeau. За три года, прошедших с того момента, как я изначально написал это, Кланг перешел от чисто экспериментального к вполне разумному для использования в производстве. Аналогичным образом, сторонники gcc (IMO) также добились больших успехов в отношении соответствия.

В то же время Comeau не выпустил ни одну новую версию своего компилятора, и появилась новая версия стандарта С++. В результате Комо сейчас довольно устарел в отношении нынешнего стандарта (и ситуация, похоже, ухудшается, а не лучше - комитет уже одобрил проект комитета нового стандарта, который, вероятно, станет C + +14).

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

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

Ответ 3

"Не сломать ничего" - это такой скользкий склон в конечном счете, что его лучше вообще избегать. Основной продукт моей компании состоял из нескольких поколений компиляторов (впервые написанных в 1991 году, с RW), а также расчесывание расширений компилятора и нарушения стандартов, когда это было время перехода на новую систему dev, потребовало больших усилий.

Но пока есть возможность отключить или хотя бы предупредить о "нестандартном расширении", я согласен с этим. 34, 70, 6.

Ответ 4

Мне бы, конечно, нужен вариант, который запрещает расширение языка для отключения всех языковых расширений. Почему?

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

"Лучше" - субъективное слово. Расширения языка полезны для некоторых разработчиков, но делают вещи более трудными для других.

Ответ 5

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

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

Итак, учитывая это, я ожидаю, что MSVC будет стандартным только по умолчанию. То же самое с gcС++.

Статистика: 40, 90, 15

Ответ 6

Я считаю, что соблюдение стандартов очень важно.

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

Как дома, так и на работе, я использую g++, и я наложил его на следующие флаги для строгого соответствия стандарту.

-Wall -Wextra -ansi -pedantic -std=c++98

Посмотрите эту страницу на Строгий ANSI/ISO

Я не эксперт по стандартам, но это хорошо послужило мне. Я написал библиотеки контейнеров в стиле STL, которые работают как на разных платформах, например. 32-разрядный Linux, 64-разрядный Linux, 32-разрядный Solaris и 32-разрядная встроенная операционная система.

Ответ 7

Рассматривать индикаторы на автомобилях (известные как "сигналы поворота" в некоторых юрисдикциях); они являются надежным способом определить, в каком направлении кто-то собирается отключить круговое движение... пока только один человек не использует их вообще. Затем вся система распадается.

Это не "повредило никому" или, очевидно, "сломало что-либо" в IE, когда они разрешили использовать document.someId в качестве ярлыка для document.getElementById('someId').... однако он породил целое поколение кодировщиков и даже книги, которые, следовательно, считали, что все в порядке и правильно, потому что "это работает". Затем, неожиданно, десять миллионов результирующих веб-сайтов были полностью не переносимыми.

Стандарты важны для интероперабельности, и если вы не будете следовать им, тогда мало смысла иметь их вообще.

Собаки, отвечающие за стандарты, могут получить ненависть за "педантизм", но на самом деле, пока все не последуют этому примеру, у вас будут проблемы с переносимостью и совместимостью навсегда.

Ответ 8

Насколько важно соблюдение стандартов, зависит от того, чего вы пытаетесь достичь.

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

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

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