Undefined behavior & Co.

[valexey_u]

Рискну предположить, что это просто напросто ум и опытность :-)

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

В случае валидных программ, по определению, UB не бывает.

рискуйте.. на здоровье, но я не вижу смысла в этом определении... один хер.. ЛЮБОЙ компилятор имеет на этот счет СВОЕ КОНКРЕТНОЕ мнение...

Ась? Чегось? В случае валидных программ под всеми платформами и компиляторами никаких UB нет. В случае не валидной программы может быть UB. Это самое UB может выражаться как угодно. Средства отладки и диагностики UB обычно ловят на раз и тыкают в него носом нерадивого программиста.

[DddIzer]

Ась? Чегось? В случае валидных программ под всеми платформами и компиляторами никаких UB нет. В случае не валидной программы может быть UB. Это самое UB может выражаться как угодно. Средства отладки и диагностики UB обычно ловят на раз и тыкают в него носом нерадивого программиста.

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

[valexey_u]

Ась? Чегось? В случае валидных программ под всеми платформами и компиляторами никаких UB нет. В случае не валидной программы может быть UB. Это самое UB может выражаться как угодно. Средства отладки и диагностики UB обычно ловят на раз и тыкают в него носом нерадивого программиста.

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

Неа, компилятор в ряде случаев отдает это дело на откуп железяке и OS, и вот там может быть уже что угодно. Причем в одной и той же программе на разных этапах могут быть совсем разные эффекты. Что собственно и наблюдаем частенько когда имеем например не валидные указатели :-) Программа то работает, то не работает, то работает странно, то комп вообще перезагружается.

[DddIzer]

Ась? Чегось? В случае валидных программ под всеми платформами и компиляторами никаких UB нет. В случае не валидной программы может быть UB. Это самое UB может выражаться как угодно. Средства отладки и диагностики UB обычно ловят на раз и тыкают в него носом нерадивого программиста.

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

Неа, компилятор в ряде случаев отдает это дело на откуп железяке и OS, и вот там может быть уже что угодно. Причем в одной и той же программе на разных этапах могут быть совсем разные эффекты. Что собственно и наблюдаем частенько когда имеем например не валидные указатели :-) Программа то работает, то не работает, то работает странно, то комп вообще перезагружается.

и даже в этом случае это вопрос конкретной реализации а не  UB.    гыы заключающаяся в том, что либо реакция не предусмотрена, либо отдана на откуп ОС с железякой

[valexey_u]

и даже в этом случае это вопрос конкретной реализации а не  UB. 

С фига ли? От компилятора тут уже ничего не зависит, да и от языка :-) Поменял железо и ось - получил для абсолютно того же бинарника совершенно другие эффекты. Радости ... полные штаны!

Ну а вообще посыл UB - в том, что это жопа, и когда жопа стряслась, то поздняк пить боржоми. Жопу следует не допускать. Типа потеряли управление самолетом (полностью) и все. Дальше можно только молиться ну и надеяться что внешняя среда будет благосклонна к данному случаю.

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

[DddIzer]

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

[DddIzer]

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

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

[valexey_u]

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

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

Ну, тут могу лишь повториться:

вы не поняли Алексей, я ЗА Implementation defined, но против UB(ибо последний отношу к некачественной архитектуре языка)

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

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

[DddIzer]

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

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

Ну, тут могу лишь повториться:

вы не поняли Алексей, я ЗА Implementation defined, но против UB(ибо последний отношу к некачественной архитектуре языка)

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

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

и я повторюсь - в каком месте ЯВУ ОПРЕДЕЛЕНО понятие ЭФФЕКТИВНОСТЬ - и требование ее от конкретной  реализации. Ровным счетом мы натыкаемся но то о чем я плевался в
соседнем топике - эфемерности понятия эффективности...

[valexey_u]

и я повторюсь - в каком месте ЯВУ ОПРЕДЕЛЕНО понятие ЭФФЕКТИВНОСТЬ - и требование ее от конкретной  реализации. Ровным счетом мы натыкаемся но то о чем я плевался в
соседнем топике - эфемерности понятия эффективности...

Ну, это уже скорее из области бизнеса: если твоя реализация скайпика выдает 15 fps при кадре 320x240 то все хорошо до тех пор пока не появится конкурент у которого на том же самом оборудовании будет 60fps при 720p. :-) Это если на рынок работать.

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

[DddIzer]

и я повторюсь - в каком месте ЯВУ ОПРЕДЕЛЕНО понятие ЭФФЕКТИВНОСТЬ - и требование ее от конкретной  реализации. Ровным счетом мы натыкаемся но то о чем я плевался в
соседнем топике - эфемерности понятия эффективности...

Ну, это уже скорее из области бизнеса: если твоя реализация скайпика выдает 15 fps при кадре 320x240 то все хорошо до тех пор пока не появится конкурент у которого на том же самом оборудовании будет 60fps при 720p. :-) Это если на рынок работать.

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

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

[valexey_u]

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

А было бы очень странно если бы Modula-2 проиграла бы в производительности Си (не С++). Чай информации для оптимизации в случае модулы ну никак не меньше, а скорее даже больше. Больше подсказок оптимизатору со стороны языка.

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

Ведь нужно при одинаковой постановке задачи найти людей (разных! одного и того же нельзя!) с примерно равным опытом. Для каждого языка - свой человек. Причем чтобы у них был равный опыт в решении задач подобного рода. И пусть они напишут решение для данной задачи, каждый на своем языке. Причем одного такого захода не достаточно. Нужно N наборов таких товарищей для одной и той же задачи. Если наборов будет хотя бы 50, задача достаточно объемна, то можно будет что-то говорить о производительности языков (с поправкой на наличие стандартных либ для данной задачи для каждого из языков).

Это достаточно дорогостоящий эксперимент. Задачу я оцениваю примерно в неделю-две (причем разработчики должны заниматься только этой задачей, то есть на честный фултайм). Это в случае 1 разработчика примерно 1000$ потратить надо (ну, может 200, может 1500 - не суть), языков понятное дело не два, а штук 5. 5*50*1000 = 250 000$ только на проведение эксперимента.

Хм, может стоит с этой идеей выйти на кикстартер? :-D

[DddIzer]

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

А было бы очень странно если бы Modula-2 проиграла бы в производительности Си (не С++). Чай информации для оптимизации в случае модулы ну никак не меньше, а скорее даже больше. Больше подсказок оптимизатору со стороны языка.

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

Ведь нужно при одинаковой постановке задачи найти людей (разных! одного и того же нельзя!) с примерно равным опытом. Для каждого языка - свой человек. Причем чтобы у них был равный опыт в решении задач подобного рода. И пусть они напишут решение для данной задачи, каждый на своем языке. Причем одного такого захода не достаточно. Нужно N наборов таких товарищей для одной и той же задачи. Если наборов будет хотя бы 50, задача достаточно объемна, то можно будет что-то говорить о производительности языков (с поправкой на наличие стандартных либ для данной задачи для каждого из языков).

Это достаточно дорогостоящий эксперимент. Задачу я оцениваю примерно в неделю-две (причем разработчики должны заниматься только этой задачей, то есть на честный фултайм). Это в случае 1 разработчика примерно 1000$ потратить надо (ну, может 200, может 1500 - не суть), языков понятное дело не два, а штук 5. 5*50*1000 = 250 000$ только на проведение эксперимента.

Хм, может стоит с этой идеей выйти на кикстартер? :-D

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

[ilovb]

Да? Ткни пожалуйста носом в пункт этого документа, где он требует GC и проверки выхода за границы массива: http://www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon07.Report.pdf

Ну как бэ...

The elements of the array are designated by indices, which are integers between 0 and the length minus 1.

Мне думается что нужно различать UB в языке и в самом компиляторе.

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

[valexey_u]

почему...  там нет ни адресной арифметики,

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

ни кучи операторов присваивания

Эмм. Какая такая куча операторов присваивания? Аля *=, += и так далее? Так это все давно не актуально, вот это как раз сейчас натуральный синтаксический сахарищще. На оптимизацию не влияет никак.

ни инкрементальных операторов

INC/DEC там вроде как раз таки есть. Вон, даже в обероне есть.

нет фокусов с интерпретацией   логических значений

А это что за фокусы и как они могут повлиять на оптимизацию?

ни модификаторов register

Эта штука уже лет 20 как не используется. Это дело по моему или уже выпилили из стандарта, или выпиливают. На оптимизацию не влияет.

ни  понятие макроподстановки либо инлайн функции..?

Макроподстановок действительно в Модуле нет, а вот инлайн-функции как раз есть ровно также как и в Си (если что, директивы inline в Сях того времени (1998 год?) просто нет).

- вороха того дерьма, которое по уверению создателей СИ способствует производительности генерируемого кода...

Если сравнивать конкретно Модулу-2 и Си (тех лет, стандарт С89/90), то я на стороне Модулы-2 безусловно. Потому, что семантически они практически одно и то же, модель исполнения едина, кроме того модула позволяет больше оптимизаций :-) При этом модула строже и вообще няшней в использовании.

Слабенький буст у сей - это макросы. Но в том виде в котором они есть в C89/90 - это таки пакость (а вот в C12 -- уже можно как-то жить).