OberonCore

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

Сложность, по всей видимости, не только в прохождении, но и в организации и методологическом сопровождении самой процедуры. Тут уже правильно отметили, что надо подложить какие-то требования и механизмы. Вдобавок ко всему - узаконенные.
Скорее всего, как предположил Alexey Veselovsky, подвижка произойдёт в форме страхования ответственности. А чтобы нечаянно не обвалить весь страховой рынок - пропедалируется в виде саморегулируемых ассоциаций "ответственных" производителей с ежегодным взносом. Как у строителей.. Мелочи приятно, а крупняку выгодно.

А у меня вот такой интересный возникает вопрос по поводу ответственности за качество.
В стандарте С++ полно мест, в которых указывается, поведение компилятора для такой-то конструкции является "undefined".
Это означает, что реализация этой оставляется на усмотрение разработчика компилятора.
Таким образом, имеем, что в компиляторе Борланда конструкция реализована одним способом, а в компиляторе Intel - сосвем другим. Результаты получаются совершенно разные. Между тем, конструкции в С++ являются совершенно легальными.
И тот и другой компилятор полностью соответствуют стандарту. Международному, между прочим!
И кто будет отвечать?

Вот, кабы Вы компилятором торговали, который хаотически то под Борланд компилит, то под Интел - тогда спрос однозначно с Вас
А в описанной Вами ситуации нет состава гражданско-правового деликта.

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

Меня ничего не смущает, пока за это нет юридической статьи...
Если статья появилась, то надо определиться, что считается, а что - не считается...

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

Опять нарушение закона тождества. Так все будут это знать и учитывать, при создании этой версии Оберон 2007. А как это учесть в С++, если даже непонятно, что учесть и каждый это понимает как хочет.

Плохой тон - это понятно. Но это - МНЕНИЕ. А теперь грозит статья...
ИМХО, пока в информационных технологиях больше благих намерений, чем реальных четких законов...
А все потому, что слишком отличается от материальной сферы...

Оцениваться будет думаю конкретная бинарная сборка в конкретных условиях. А не сферические исходники в вакууме.

Стандарт на язык явно указывает тебе места где возможны разночтения разными компиляторами/платформами. Твоё дело это принять к сведению и сделать так, чтобы оные разночтения не привели к ошибкам в твоей программе (конкретных сборках твоей программы). Частным случаем избегания таковых ошибок является неиспользование кода у которого UB. Всё. В чем проблема то?

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

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

Поэтому например размеры типов и их диапазоны значений в стандарте не указаны.

В отличае от той же явы, C++ язык кроссплатформенный.

Трудно согласиться.

Алексей, можешь поинтересоваться у Когана или у Четырьбока почему они не могут собрать Windows версию библиотеки libmgenericnode.so написанную на С++

(мы с Алексеем в одной компании работаем в одной комнате в двух "кубиках" друг от друга сидим)

Тут штука такая: язык кроссплатформенный, а вот программа писаная на этом языке -- совсем не обязательно

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

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

Например выравнивание: преобразование из char* к int* на x86 пройдёт на ура всегда, в ARM'e же в трех случаях из четырёх процессор не сможет обратиться к int'у по этому адресу, ибо данные должны быть выровнены.

Не исключено.

В принципе - еще одно свидетельство постепенного перехода разработки ПО ближе к стадии зрелости, от "свободного искусства" - к хотя бы ремеслу, или, как удачно сказал Илья Ермаков, "от знахарства к науке".

Пользователь.

В принципе, если в договоре на выполнение работ прописаны некие требования к интерфейсу (или, говоря о мелких буквах на 22353 странице - к документации), то вопрос может стать и спорным.

Если не было таких требований - ничего не поделаешь, виноват пользователь.

Пппереведи

А в программировании - отдел QA (Quality Assurance) по идее должен контролировать, чтобы писали правильно...