Oberon space
General Category => Общий раздел => Тема начата: valexey_u от Март 28, 2013, 02:07:59 pm
-
У столь широко разрекламированного UB есть еще братья, сестры и кузины. Они все разные и их следует различать.
Кроме undefined behavior еще бывает unspecified behavior, implementation-defined behavior, locale-specific behavior.
И хотя эта терминология взята из стандарта С++, сами эти замечательные друзья существуют практически во всех языках, в том же Обероне например (но там они явно не прописаны, так что приходится догадываться).
Чем они все отличаются друг от друга можно прочесть (кратко и на русском) вот тут: http://alenacpp.blogspot.ru/2005/08/unspecified-behavior-undefined.html
-
ну не... по идее UB должно отлавливаться как ошибка(алгоритм не может быть интерпретирован языком), в отличии от realization depended...
а в каком месте в описании Оберона (или КП) есть UB? вроде как то я их не видел?
-
ну не... по идее UB должно отлавливаться как ошибка(алгоритм не может быть интерпретирован языком), в отличии от realization depended...
а в каком месте в описании Оберона (или КП) есть UB? вроде как то я их не видел?
Ни в одном из описаний, насколько я помню, четко UB не прописано (видимо на символах экономили, чтобы в 16 страниц влезло), но они там очевидно есть. Ну, например там умалчивается что будет если поделить на ноль. Это явное UB. Ну и что будет после разименовывания нулевого указателя.
-
ну не... по идее UB должно отлавливаться как ошибка(алгоритм не может быть интерпретирован языком), в отличии от realization depended...
а в каком месте в описании Оберона (или КП) есть UB? вроде как то я их не видел?
Ни в одном из описаний, насколько я помню, четко UB не прописано (видимо на символах экономили, чтобы в 16 страниц влезло), но они там очевидно есть. Ну, например там умалчивается что будет если поделить на ноль. Это явное UB. Ну и что будет после разименовывания нулевого указателя.
с чего бы это.. я так понимаю , что если что то не прописано, значит это realization depended....
правда есть поганенький вопрос в сторону оберонов- а много ли приходится доопределять реализацией в Оберонах, и как это может повлиять на портабельность программ..
-
ну не... по идее UB должно отлавливаться как ошибка(алгоритм не может быть интерпретирован языком), в отличии от realization depended...
а в каком месте в описании Оберона (или КП) есть UB? вроде как то я их не видел?
Ни в одном из описаний, насколько я помню, четко UB не прописано (видимо на символах экономили, чтобы в 16 страниц влезло), но они там очевидно есть. Ну, например там умалчивается что будет если поделить на ноль. Это явное UB. Ну и что будет после разименовывания нулевого указателя.
с чего бы это.. я так понимаю , что если что то не прописано, значит это realization depended....
правда есть поганенький вопрос в сторону оберонов- а много ли приходится доопределять реализацией в Оберонах, и как это может повлиять на портабельность программ..
Это не является implementation-defined behavior просто потому, что implementation-defined behavior подразумевает что оно случается когда программа валидная, то есть будет точно хорошо, причем всегда одним и тем же способом, а как именно будет - см. доку на реализацию.
В случае деления на ноль - хорошо не будет :-) Да и в случае попытки пролезть по нулевому указателю тоже хорошо не будет.
Причем в случаях unspecified behavior, implementation-defined behavior это все должно быть явно указано в доке на язык а не реализацию.
Так что, если оставаться в терминах всех этих 4х behavior'ов, то остается только UB.
-
Это не является implementation-defined behavior просто потому, что implementation-defined behavior подразумевает что оно случается когда программа валидная,
а вот это с чего?
-
Это не является implementation-defined behavior просто потому, что implementation-defined behavior подразумевает что оно случается когда программа валидная,
а вот это с чего?
С этого:
--implementation-defined behavior: Behavior, for a well-formed program
construct and correct data, that depends on the implementation and
that each implementation shall document.
http://www.csci.csusb.edu/dick/c++std/cd2/intro.html#intro.defs
-
Это не является implementation-defined behavior просто потому, что implementation-defined behavior подразумевает что оно случается когда программа валидная,
а вот это с чего?
С этого:
--implementation-defined behavior: Behavior, for a well-formed program
construct and correct data, that depends on the implementation and
that each implementation shall document.
http://www.csci.csusb.edu/dick/c++std/cd2/intro.html#intro.defs
так это же определение из стана "врагов" .. там они дофига чего могут определить... вопрос в том, стоит ли их определениями пользоваться при трактовке Оберонного кода...
-
http://www.csci.csusb.edu/dick/c++std/cd2/intro.html#intro.defs
так это же определение из стана "врагов" .. там они дофига чего могут определить... вопрос в том, стоит ли их определениями пользоваться при трактовке Оберонного кода...
Ну, я же сказал, что "если оставаться в терминах всех этих 4х behavior'ов, то остается только UB.", если же начать фантазировать и придумывать свои определения этой четверки, то конечно можно будет подогнать под что угодно :-)
Но мне эта четвёрка представляется вполне разумной, не вижу смысла как-то это изменять плодя сущности.
-
Но мне эта четвёрка представляется вполне разумной, не вижу смысла как-то это изменять плодя сущности.
так я иду дальше.. уменьшаю четверку.. до одной сущности, ибо не вижу с точки зрения языка (Оберона) плодить их... но может быть это необходимо с точки зрения реализации?
-
Но мне эта четвёрка представляется вполне разумной, не вижу смысла как-то это изменять плодя сущности.
так я иду дальше.. уменьшаю четверку.. до одной сущности, ибо не вижу с точки зрения языка (Оберона) плодить их... но может быть это необходимо с точки зрения реализации?
Ну, конечно же есть. И для использования тоже - например тот же порядок вычислений аргументов функции - это типичный UsB а не UB :-)
Можно конечно заняться и сгенерить списочек всех этих B для оберона. Правда добавится пятый вариант под именем "ХЗ", ибо местами вообще там не ясно какое должно быть поведение (с точки зрения конструкций языка, типов, областей видимости).
То есть проблема оберона в том, что там UB распространяется не только на приложение которое собрано каким-то конкретным компилятором, но и на сам компилятор. Одну и ту же программу не противоречащую сообщению о языке, один компилятор в полном соответствии с описанием языка может собрать, а другой не собрать. И все тут будут правы.
-
Но мне эта четвёрка представляется вполне разумной, не вижу смысла как-то это изменять плодя сущности.
так я иду дальше.. уменьшаю четверку.. до одной сущности, ибо не вижу с точки зрения языка (Оберона) плодить их... но может быть это необходимо с точки зрения реализации?
Ну, конечно же есть. И для использования тоже - например тот же порядок вычислений аргументов функции - это типичный UsB а не UB :-)
Можно конечно заняться и сгенерить списочек всех этих B для оберона. Правда добавится пятый вариант под именем "ХЗ", ибо местами вообще там не ясно какое должно быть поведение (с точки зрения конструкций языка, типов, областей видимости).
То есть проблема оберона в том, что там UB распространяется не только на приложение которое собрано каким-то конкретным компилятором, но и на сам компилятор. Одну и ту же программу не противоречащую сообщению о языке, один компилятор в полном соответствии с описанием языка может собрать, а другой не собрать. И все тут будут правы.
вы не поняли Алексей, я ЗА Implementation defined, но против UB(ибо последний отношу к некачественной архитектуре языка)
-
вы не поняли Алексей, я ЗА Implementation defined, но против UB(ибо последний отношу к некачественной архитектуре языка)
UB это всегда плата за эффективность. Грубо говоря, оно нужно чтобы не пришлось вокруг нашего языка каждый раз строить виртуальную машину в которой было бы все так одинаково везде да предсказуемо.
Ну, то есть возможно где-то и существует язык который и портабельный и эффективный и имеет множество реализаций и высокоуровневый и при этом без UB, но я такого не встречал пока (среди тех, что копал достаточно глубоко).
-
например, разименование NIL - указателя.. не имеет смысла с точки зрения обьектов порождаемых языком.. - а поскольку явно в описание ничего про это не говорится,
то возможной обработкой этой ситуации (с точки зрения реализации) может быть рантайм проверка (аналогичная проверки границы индексов массива).
-
например, разименование NIL - указателя.. не имеет смысла с точки зрения обьектов порождаемых языком.. - а поскольку явно в описание ничего про это не говорится,
то возможной обработкой этой ситуации (с точки зрения реализации) может быть рантайм проверка (аналогичная проверки границы индексов массива).
Кстати, да, выход за границу индексов массива это еще один UB в Обероне :-)
-
UB это всегда плата за эффективность.
Вы судите мерками С языков.. Оберон понятие "эффективность" и \эффективность реализации, в частности - НЕ ОПРЕДЕЛЯЕТ...
-
Кстати, да, выход за границу индексов массива это еще один UB в Обероне :-)
наоборот.. это одна из немногих вещей которые он ТРЕБУЕТ от реализации не определяя ( другая такая вещь GC)
-
Кстати, да, выход за границу индексов массива это еще один UB в Обероне :-)
наоборот.. это одна из немногих вещей которые он ТРЕБУЕТ от реализации не определяя ( другая такая вещь GC)
Да? Ткни пожалуйста носом в пункт этого документа, где он требует GC и проверки выхода за границы массива: http://www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon07.Report.pdf
-
Кстати, да, выход за границу индексов массива это еще один UB в Обероне :-)
наоборот.. это одна из немногих вещей которые он ТРЕБУЕТ от реализации не определяя ( другая такая вещь GC)
Да? Ткни пожалуйста носом в пункт этого документа, где он требует GC и проверки выхода за границы массива: http://www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon07.Report.pdf
я имею ввиду нормальный Оберон, а не кастрированный. лень искать но припоминаю нечто вроде.."реализация без GC - не может считаться Обероном".
-
Кстати, да, выход за границу индексов массива это еще один UB в Обероне :-)
наоборот.. это одна из немногих вещей которые он ТРЕБУЕТ от реализации не определяя ( другая такая вещь GC)
Да? Ткни пожалуйста носом в пункт этого документа, где он требует GC и проверки выхода за границы массива: http://www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon07.Report.pdf
я имею ввиду нормальный Оберон, а не кастрированный. лень искать но припоминаю нечто вроде.."реализация без GC - не может считаться Обероном".
Вот не кастрированный, оригинальный, от 1990 года: http://www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon.Report.pdf
Попробуй найти там.
-
нашел в КП
Приложение D: Обязательные требования к среде выполнения
Определение Компонентного Паскаля опирается на три фундаментальных предположения.
1)Во время исполнения программ доступна информация, позволяющая проверять динамический тип объекта. Это нужно для реализации проверок типов и охраны типов.
2)Отсутствует процедура DISPOSE <освобождение памяти, занятой более не используемыми объектами>. Память не может быть освобождена по явной инструкции программиста, поскольку это создало бы проблемы безопасности, связанные с утечками памяти [memory leaks] и с висячими указателями [dangling pointers]. За исключением таких встроенных систем, где не используется динамическое управление памятью, или где ее можно разместить только однажды и никогда не нужно освобождать, требуется автоматический сбор мусора.
3)Модули и по крайней мере их экспортированные процедуры (команды) и экспортированные типы должны быть доступны динамически. В случае необходимости это может вызывать загрузку модулей. Программный интерфейс, используемый для загрузки модулей или для доступа к указанной мета-информации, не определяется языком, но компилятор должен сохранять эту информацию при генерации кода.
За исключением полностью слинкованных приложений, в которых при исполнения не нужно загружать никакие модули, для модулей требуется динамический загрузчик. Встроенные системы являются важными примерами приложений, которые могут быть полностью слинкованы.
Реализация, которая не удовлетворяет этим требованиям к компилятору и среде выполнения, не считается удовлетворяющей определению Компонентного Паскаля.
-
нашел в КП
...
Реализация, которая не удовлетворяет этим требованиям к компилятору и среде выполнения, не считается удовлетворяющей определению Компонентного Паскаля.
А при чем тут Оберон? Я ведь про Оберон говорил, если б я говорил про какое-то ответвление от Оберона (ну, там про Зоннон, или КП, или про Object Oberon), я бы прямо об этом сказал.
-
нашел в КП
...
Реализация, которая не удовлетворяет этим требованиям к компилятору и среде выполнения, не считается удовлетворяющей определению Компонентного Паскаля.
А при чем тут Оберон? Я ведь про Оберон говорил, если б я говорил про какое-то ответвление от Оберона (ну, там про Зоннон, или КП, или про Object Oberon), я бы прямо об этом сказал.
в данной модификации Оберона это прописано в явном виде(память не обманула... хотя читал я это года 4 назад)... а если в других модификациях O7, O ,...- этого нет.. значит это субьект Implementation defined (ну если не поддерживает железо реализацию динамически распределяемую память.. какая там может быть GC...)- но отнюдь не UB
-
точнее .. я ошибся приписав свойства CP Оберону... но суть вопроса, имхо это не меняет.
-
нашел в КП
...
Реализация, которая не удовлетворяет этим требованиям к компилятору и среде выполнения, не считается удовлетворяющей определению Компонентного Паскаля.
А при чем тут Оберон? Я ведь про Оберон говорил, если б я говорил про какое-то ответвление от Оберона (ну, там про Зоннон, или КП, или про Object Oberon), я бы прямо об этом сказал.
в данной модификации Оберона это прописано в явном виде(память не обманула... хотя читал я это года 4 назад)... а если в других модификациях O7, O ,...- этого нет.. значит это субьект Implementation defined (ну если не поддерживает железо реализацию динамически распределяемую память.. какая там может быть GC...)- но отнюдь не UB
Ога, ога, а D это модификация Алгола-68.
КП это другой язык, не Оберон и не его развитие. Он принадлежит к ветке языков с общим предком под названием Object Oberon.
implementation-defined behavior - это все же когда конкретная РЕАЛИЗАЦИЯ языка (то есть конкетный компилятор) вносит какую-то свою специфику и возможность возникновение таковой специфики предусмотрено описанием (спецификацией) языка.
А то что мы имеем тут - это куст разных СПЕЦИФИКАЦИЙ языков, языки родственные, но это не один и тот же язык. Про их реализации вообще речи не идет.
Так что извини, но тут у тебя логика хромает на обе ноги.
PS. Кстати, даже в описании КП я не нашел места где было бы сказано, что конструкция a := b[j]; вызывала бы run-time error в случае если j выходит за диапазон. Да, тут b является массивов произвольных сущностей (рекордов каких-то или же integer'ов, не важно).
-
нашел в КП
...
Реализация, которая не удовлетворяет этим требованиям к компилятору и среде выполнения, не считается удовлетворяющей определению Компонентного Паскаля.
А при чем тут Оберон? Я ведь про Оберон говорил, если б я говорил про какое-то ответвление от Оберона (ну, там про Зоннон, или КП, или про Object Oberon), я бы прямо об этом сказал.
в данной модификации Оберона это прописано в явном виде(память не обманула... хотя читал я это года 4 назад)... а если в других модификациях O7, O ,...- этого нет.. значит это субьект Implementation defined (ну если не поддерживает железо реализацию динамически распределяемую память.. какая там может быть GC...)- но отнюдь не UB
Ога, ога, а D это модификация Алгола-68.
КП это другой язык, не Оберон и не его развитие. Он принадлежит к ветке языков с общим предком под названием Object Oberon.
implementation-defined behavior - это все же когда конкретная РЕАЛИЗАЦИЯ языка (то есть конкетный компилятор) вносит какую-то свою специфику и возможность возникновение таковой специфики предусмотрено описанием (спецификацией) языка.
А то что мы имеем тут - это куст разных СПЕЦИФИКАЦИЙ языков, языки родственные, но это не один и тот же язык. Про их реализации вообще речи не идет.
Так что извини, но тут у тебя логика хромает на обе ноги.
PS. Кстати, даже в описании КП я не нашел места где было бы сказано, что конструкция a := b[j]; вызывала бы run-time error в случае если j выходит за диапазон. Да, тут b является массивов произвольных сущностей (рекордов каких-то или же integer'ов, не важно).
см комментарий ВЫШЕ :)
-
см комментарий ВЫШЕ :)
Если уж на то пошло, то какое-то упоминание про GC появилось в Обероне-2 (это тоже ответвление от основного ствола оберонов и КП является потомком Оберона-2).
-
еще раз, я могу понять, когда язык спроектирован (описан) недостаточно полно... то есть допускает неоднозначную реализацию .. но когда САМИ СОЗДАТЕЛИ ЯП - определяют понятие UB это хрен знает что...
-
еще раз, я могу понять, когда язык спроектирован (описан) недостаточно полно... то есть допускает неоднозначную реализацию .. но когда САМИ СОЗДАТЕЛИ ЯП - определяют понятие UB это хрен знает что...
Рискну предположить, что это просто напросто ум и опытность :-)
Поведение определяется не только желаниями архитектора языка, но и той железякой которая внизу работает. И архитектор языка может точно указать в каких случаях программа будет не валидной, а дальнейшее поведение будет зависеть от причуд железяки, окружения и так далее.
В случае валидных программ, по определению, UB не бывает.
-
Рискну предположить, что это просто напросто ум и опытность :-)
Поведение определяется не только желаниями архитектора языка, но и той железякой которая внизу работает. И архитектор языка может точно указать в каких случаях программа будет не валидной, а дальнейшее поведение будет зависеть от причуд железяки, окружения и так далее.
В случае валидных программ, по определению, UB не бывает.
рискуйте.. на здоровье, но я не вижу смысла в этом определении... один хер.. ЛЮБОЙ компилятор имеет на этот счет СВОЕ КОНКРЕТНОЕ мнение...
-
Рискну предположить, что это просто напросто ум и опытность :-)
Поведение определяется не только желаниями архитектора языка, но и той железякой которая внизу работает. И архитектор языка может точно указать в каких случаях программа будет не валидной, а дальнейшее поведение будет зависеть от причуд железяки, окружения и так далее.
В случае валидных программ, по определению, UB не бывает.
рискуйте.. на здоровье, но я не вижу смысла в этом определении... один хер.. ЛЮБОЙ компилятор имеет на этот счет СВОЕ КОНКРЕТНОЕ мнение...
Ась? Чегось? В случае валидных программ под всеми платформами и компиляторами никаких UB нет. В случае не валидной программы может быть UB. Это самое UB может выражаться как угодно. Средства отладки и диагностики UB обычно ловят на раз и тыкают в него носом нерадивого программиста.
-
Ась? Чегось? В случае валидных программ под всеми платформами и компиляторами никаких UB нет. В случае не валидной программы может быть UB. Это самое UB может выражаться как угодно. Средства отладки и диагностики UB обычно ловят на раз и тыкают в него носом нерадивого программиста.
тогось... о чем я говорю - компилятор разрешает неопределенность вполне конкретным способом (как в ваших примерах с двумя разными UB), а насчет средств отладки и диагностики...- это отдельная песня
-
Ась? Чегось? В случае валидных программ под всеми платформами и компиляторами никаких UB нет. В случае не валидной программы может быть UB. Это самое UB может выражаться как угодно. Средства отладки и диагностики UB обычно ловят на раз и тыкают в него носом нерадивого программиста.
тогось... о чем я говорю - компилятор разрешает неопределенность вполне конкретным способом (как в ваших примерах с двумя разными UB), а насчет средств отладки и диагностики...- это отдельная песня
Неа, компилятор в ряде случаев отдает это дело на откуп железяке и OS, и вот там может быть уже что угодно. Причем в одной и той же программе на разных этапах могут быть совсем разные эффекты. Что собственно и наблюдаем частенько когда имеем например не валидные указатели :-) Программа то работает, то не работает, то работает странно, то комп вообще перезагружается.
-
Ась? Чегось? В случае валидных программ под всеми платформами и компиляторами никаких UB нет. В случае не валидной программы может быть UB. Это самое UB может выражаться как угодно. Средства отладки и диагностики UB обычно ловят на раз и тыкают в него носом нерадивого программиста.
тогось... о чем я говорю - компилятор разрешает неопределенность вполне конкретным способом (как в ваших примерах с двумя разными UB), а насчет средств отладки и диагностики...- это отдельная песня
Неа, компилятор в ряде случаев отдает это дело на откуп железяке и OS, и вот там может быть уже что угодно. Причем в одной и той же программе на разных этапах могут быть совсем разные эффекты. Что собственно и наблюдаем частенько когда имеем например не валидные указатели :-) Программа то работает, то не работает, то работает странно, то комп вообще перезагружается.
и даже в этом случае это вопрос конкретной реализации а не UB. ;) гыы заключающаяся в том, что либо реакция не предусмотрена, либо отдана на откуп ОС с железякой
-
и даже в этом случае это вопрос конкретной реализации а не UB. ;)
С фига ли? От компилятора тут уже ничего не зависит, да и от языка :-) Поменял железо и ось - получил для абсолютно того же бинарника совершенно другие эффекты. Радости ... полные штаны!
Ну а вообще посыл UB - в том, что это жопа, и когда жопа стряслась, то поздняк пить боржоми. Жопу следует не допускать. Типа потеряли управление самолетом (полностью) и все. Дальше можно только молиться ну и надеяться что внешняя среда будет благосклонна к данному случаю.
В случае там всяких яв, шарпов и так далее, их самолеты предпочитают летать исключительно в своей среде (надувают воздушный шарик вокруг самолета и в нем и летают), которая ведет себя предсказуемо, всегда одинаково, и всегда одинаково благосклонна (на крайняк врежешься в стенку шарика, да там и прилипнешь). Правда вместе с этим шариком не везде получается пролезть :-) Ну и перемещаться получается далеко не быстро.
-
впрочем, Алексей, я не утверждаю что понятие UB бессмысленно в языке С++, просто, весьма настороженно отношусь к репликации этого понятия и сопутствующих ему (вы определили их в заголовке топика) на произвольный ЯП...
-
В случае там всяких яв, шарпов и так далее, их самолеты предпочитают летать исключительно в своей среде (надувают воздушный шарик вокруг самолета и в нем и летают), которая ведет себя предсказуемо, всегда одинаково, и всегда одинаково благосклонна (на крайняк врежешься в стенку шарика, да там и прилипнешь). Правда вместе с этим шариком не везде получается пролезть :-) Ну и перемещаться получается далеко не быстро.
да, я про это и говорю см. пост выше... то есть из того что СИ++ спроектирован херовато (и этому есть весьма обьектвные причины - например, тяжелое наследие , в виде совместимости с СИ) - не следует, что говном должно быть все..
-
В случае там всяких яв, шарпов и так далее, их самолеты предпочитают летать исключительно в своей среде (надувают воздушный шарик вокруг самолета и в нем и летают), которая ведет себя предсказуемо, всегда одинаково, и всегда одинаково благосклонна (на крайняк врежешься в стенку шарика, да там и прилипнешь). Правда вместе с этим шариком не везде получается пролезть :-) Ну и перемещаться получается далеко не быстро.
да, я про это и говорю см. пост выше... то есть из того что СИ++ спроектирован херовато (и этому есть весьма обьектвные причины - например, тяжелое наследие , в виде совместимости с СИ) - не следует, что говном должно быть все..
Ну, тут могу лишь повториться:
вы не поняли Алексей, я ЗА Implementation defined, но против UB(ибо последний отношу к некачественной архитектуре языка)
UB это всегда плата за эффективность. Грубо говоря, оно нужно чтобы не пришлось вокруг нашего языка каждый раз строить виртуальную машину в которой было бы все так одинаково везде да предсказуемо.
Ну, то есть возможно где-то и существует язык который и портабельный и эффективный и имеет множество реализаций и высокоуровневый и при этом без UB, но я такого не встречал пока (среди тех, что копал достаточно глубоко).
-
В случае там всяких яв, шарпов и так далее, их самолеты предпочитают летать исключительно в своей среде (надувают воздушный шарик вокруг самолета и в нем и летают), которая ведет себя предсказуемо, всегда одинаково, и всегда одинаково благосклонна (на крайняк врежешься в стенку шарика, да там и прилипнешь). Правда вместе с этим шариком не везде получается пролезть :-) Ну и перемещаться получается далеко не быстро.
да, я про это и говорю см. пост выше... то есть из того что СИ++ спроектирован херовато (и этому есть весьма обьектвные причины - например, тяжелое наследие , в виде совместимости с СИ) - не следует, что говном должно быть все..
Ну, тут могу лишь повториться:
вы не поняли Алексей, я ЗА Implementation defined, но против UB(ибо последний отношу к некачественной архитектуре языка)
UB это всегда плата за эффективность. Грубо говоря, оно нужно чтобы не пришлось вокруг нашего языка каждый раз строить виртуальную машину в которой было бы все так одинаково везде да предсказуемо.
Ну, то есть возможно где-то и существует язык который и портабельный и эффективный и имеет множество реализаций и высокоуровневый и при этом без UB, но я такого не встречал пока (среди тех, что копал достаточно глубоко).
и я повторюсь - в каком месте ЯВУ ОПРЕДЕЛЕНО понятие ЭФФЕКТИВНОСТЬ - и требование ее от конкретной реализации. Ровным счетом мы натыкаемся но то о чем я плевался в
соседнем топике - эфемерности понятия эффективности...
-
и я повторюсь - в каком месте ЯВУ ОПРЕДЕЛЕНО понятие ЭФФЕКТИВНОСТЬ - и требование ее от конкретной реализации. Ровным счетом мы натыкаемся но то о чем я плевался в
соседнем топике - эфемерности понятия эффективности...
Ну, это уже скорее из области бизнеса: если твоя реализация скайпика выдает 15 fps при кадре 320x240 то все хорошо до тех пор пока не появится конкурент у которого на том же самом оборудовании будет 60fps при 720p. :-) Это если на рынок работать.
А если работать не на рынок, то все конечно определяется задачей. Впихуем нужный функционал реализованный на данном ЯП в нужную железяку с заданными ограничениями, или же не впихуем.
-
и я повторюсь - в каком месте ЯВУ ОПРЕДЕЛЕНО понятие ЭФФЕКТИВНОСТЬ - и требование ее от конкретной реализации. Ровным счетом мы натыкаемся но то о чем я плевался в
соседнем топике - эфемерности понятия эффективности...
Ну, это уже скорее из области бизнеса: если твоя реализация скайпика выдает 15 fps при кадре 320x240 то все хорошо до тех пор пока не появится конкурент у которого на том же самом оборудовании будет 60fps при 720p. :-) Это если на рынок работать.
А если работать не на рынок, то все конечно определяется задачей. Впихуем нужный функционал реализованный на данном ЯП в нужную железяку с заданными ограничениями, или же не впихуем.
ОК.. это понятно, хотя это немного и из другой оперы, разумеется можно услышать от авторов яп что их детище спроектировано таким образом, чтобы обеспечить производительную реализацию - тот же недавно упомянутый вами Дартс, но что вы скажете о реализации XDS... которая обеспечивала сравнимую с сишной производительность.
-
но что вы скажете о реализации XDS... которая обеспечивала сравнимую с сишной производительность.
А было бы очень странно если бы Modula-2 проиграла бы в производительности Си (не С++). Чай информации для оптимизации в случае модулы ну никак не меньше, а скорее даже больше. Больше подсказок оптимизатору со стороны языка.
Ну, а кроме того, я пока не видел действительно корректных бенчмарков языков. Их очень сложно устроить - микробенчмарк ничего не дает (тут всегда будет побеждать асм, хотя на задачах реального размера асм очень часто проигрывает в производительности), макробенчмарк же устроить очень сложно.
Ведь нужно при одинаковой постановке задачи найти людей (разных! одного и того же нельзя!) с примерно равным опытом. Для каждого языка - свой человек. Причем чтобы у них был равный опыт в решении задач подобного рода. И пусть они напишут решение для данной задачи, каждый на своем языке. Причем одного такого захода не достаточно. Нужно N наборов таких товарищей для одной и той же задачи. Если наборов будет хотя бы 50, задача достаточно объемна, то можно будет что-то говорить о производительности языков (с поправкой на наличие стандартных либ для данной задачи для каждого из языков).
Это достаточно дорогостоящий эксперимент. Задачу я оцениваю примерно в неделю-две (причем разработчики должны заниматься только этой задачей, то есть на честный фултайм). Это в случае 1 разработчика примерно 1000$ потратить надо (ну, может 200, может 1500 - не суть), языков понятное дело не два, а штук 5. 5*50*1000 = 250 000$ только на проведение эксперимента.
Хм, может стоит с этой идеей выйти на кикстартер? :-D
-
но что вы скажете о реализации XDS... которая обеспечивала сравнимую с сишной производительность.
А было бы очень странно если бы Modula-2 проиграла бы в производительности Си (не С++). Чай информации для оптимизации в случае модулы ну никак не меньше, а скорее даже больше. Больше подсказок оптимизатору со стороны языка.
Ну, а кроме того, я пока не видел действительно корректных бенчмарков языков. Их очень сложно устроить - микробенчмарк ничего не дает (тут всегда будет побеждать асм, хотя на задачах реального размера асм очень часто проигрывает в производительности), макробенчмарк же устроить очень сложно.
Ведь нужно при одинаковой постановке задачи найти людей (разных! одного и того же нельзя!) с примерно равным опытом. Для каждого языка - свой человек. Причем чтобы у них был равный опыт в решении задач подобного рода. И пусть они напишут решение для данной задачи, каждый на своем языке. Причем одного такого захода не достаточно. Нужно N наборов таких товарищей для одной и той же задачи. Если наборов будет хотя бы 50, задача достаточно объемна, то можно будет что-то говорить о производительности языков (с поправкой на наличие стандартных либ для данной задачи для каждого из языков).
Это достаточно дорогостоящий эксперимент. Задачу я оцениваю примерно в неделю-две (причем разработчики должны заниматься только этой задачей, то есть на честный фултайм). Это в случае 1 разработчика примерно 1000$ потратить надо (ну, может 200, может 1500 - не суть), языков понятное дело не два, а штук 5. 5*50*1000 = 250 000$ только на проведение эксперимента.
Хм, может стоит с этой идеей выйти на кикстартер? :-D
почему... там нет ни адресной арифметики, ни кучи операторов присваивания, ни инкрементальных операторов, нет фокусов с интерпретацией логических значений, ни модификаторов register, ни понятие макроподстановки либо инлайн функции..? - вороха того дерьма, которое по уверению создателей СИ способствует производительности генерируемого кода...
-
Да? Ткни пожалуйста носом в пункт этого документа, где он требует 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 в языке.
-
почему... там нет ни адресной арифметики,
В модуле-2 адресная арифметика, при желании, есть. Кроме того, оная адресная арифметика как раз припятствует некоторым оптимизациям, либо делает их сложнее.
ни кучи операторов присваивания
Эмм. Какая такая куча операторов присваивания? Аля *=, += и так далее? Так это все давно не актуально, вот это как раз сейчас натуральный синтаксический сахарищще. На оптимизацию не влияет никак.
ни инкрементальных операторов
INC/DEC там вроде как раз таки есть. Вон, даже в обероне есть.
нет фокусов с интерпретацией логических значений
А это что за фокусы и как они могут повлиять на оптимизацию?
ни модификаторов register
Эта штука уже лет 20 как не используется. Это дело по моему или уже выпилили из стандарта, или выпиливают. На оптимизацию не влияет.
ни понятие макроподстановки либо инлайн функции..?
Макроподстановок действительно в Модуле нет, а вот инлайн-функции как раз есть ровно также как и в Си (если что, директивы inline в Сях того времени (1998 год?) просто нет).
- вороха того дерьма, которое по уверению создателей СИ способствует производительности генерируемого кода...
Если сравнивать конкретно Модулу-2 и Си (тех лет, стандарт С89/90), то я на стороне Модулы-2 безусловно. Потому, что семантически они практически одно и то же, модель исполнения едина, кроме того модула позволяет больше оптимизаций :-) При этом модула строже и вообще няшней в использовании.
Слабенький буст у сей - это макросы. Но в том виде в котором они есть в C89/90 - это таки пакость (а вот в C12 -- уже можно как-то жить).
-
Да? Ткни пожалуйста носом в пункт этого документа, где он требует 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 в языке.
А ничего, что это задача о останове? То есть компилятор на этапе компиляции, в общем случае, не сможет это проверить в принципе (в рамках Оберона).
-
Да? Ткни пожалуйста носом в пункт этого документа, где он требует 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 в языке.
имхо лучше не использовать вообще это понятие, без необходимости (я проталкиваю эту мыслю :), ну пытаюсь.. ради развлечения )... а проверка на выход имеет мало общего с тем на что вы указали.. ибо может выбивать на неправильных введенных данных ... при правильной логике программы(в общем случае это субьект времени выполнения)
-
А ничего, что это задача о останове? То есть компилятор на этапе компиляции, в общем случае, не сможет это проверить в принципе (в рамках Оберона).
Ну тык исключение времени выполнения еще есть :)
ps Это херово... да. Но так уж определено в языке
-
А ничего, что это задача о останове? То есть компилятор на этапе компиляции, в общем случае, не сможет это проверить в принципе (в рамках Оберона).
Ну тык исключение времени выполнения еще есть :)
ps Это херово... да. Но так уж определено в языке
тык в том то и дело , что это либо субьект доопределения компилятором (например невозможность отключения рантайм проверки)... либо просто отдается на откуп системе и железу.
-
Я клоню к тому, что если так рассуждать то весь язык можно UB назвать.
1. Не определена операция сложения указателей? UB!
2. Не определен выстрел себе в голову из кольта? UB!
3. И т.д. :D
-
А ничего, что это задача о останове? То есть компилятор на этапе компиляции, в общем случае, не сможет это проверить в принципе (в рамках Оберона).
Ну тык исключение времени выполнения еще есть :)
ps Это херово... да. Но так уж определено в языке
Что такое "исключение" в рамках ЯП Оберон?
-
тык в том то и дело , что это либо субьект доопределения компилятором (например невозможность отключения рантайм проверки)... либо просто отдается на откуп системе и железу.
Я всегда считал, что используя всякие шаловливые ключики компилятора, кодер должен полностью отдавать себе отчет в том, что он сим действием забил хер на язык.
-
Я клоню к тому, что если так рассуждать то весь язык можно UB назвать.
1. Не определена операция сложения указателей? UB!
В репорте четко сказано, что плюсик бывает только для численных типов (и тогда он вот такой) и для множеств (и тогда он вот такой). Все остальное - не валидно. То есть это ошибка времени компиляции (типы проверяются на этапе компиляции).
А вот с описанием рантайма, и рантаймовых ошибок у Вирта полный тухляк. То есть какие они бывают, как их обрабатывать, когда возникают и так далее.
Мне представляется, что текущий Оберон-репорт нужно обозвать Core language, а для embedded, desktop/server и так далее, добивать конкретику Annex'ами.
А доопределять это дело конкретными компиляторами - это дело последнее и не правильное. Ибо язык будет бесконечно дробиться на диалекты (одна реализация - один диалект).
-
Что такое "исключение" в рамках ЯП Оберон?
Ну определение самопальное конечно :D
"Остановка выполнения программы в месте возникновения ошибки"
Т.е. в идеале либо на этапе компиляции, либо во время выполнения процесс должен быть прерван в тот момент когда программа выходит за рамки дозволенного в языке.
-
Я клоню к тому, что если так рассуждать то весь язык можно UB назвать.
1. Не определена операция сложения указателей? UB!
В репорте четко сказано, что плюсик бывает только для численных типов (и тогда он вот такой) и для множеств (и тогда он вот такой). Все остальное - не валидно.
Ну тык точно также четко определен диапазон индексов для массивов. Я же привел цитату.
То есть это ошибка времени компиляции (типы проверяются на этапе компиляции).
А по-твоему язык определяет только время компиляции?
-
тык в том то и дело , что это либо субьект доопределения компилятором (например невозможность отключения рантайм проверки)... либо просто отдается на откуп системе и железу.
Я всегда считал, что используя всякие шаловливые ключики компилятора, кодер должен полностью отдавать себе отчет в том, что он сим действием забил хер на язык.
если язык говно (поведение ни прямо ни косвенно не прописано)... точнее - воспользовался особенностями конкретной реализации... но ведь есть еще и левые диагностические ключики- глючики... подчеркивающие интеллектуальность компилятора.
-
Что такое "исключение" в рамках ЯП Оберон?
Ну определение самопальное конечно :D
"Остановка выполнения программы в месте возникновения ошибки"
Т.е. в идеале либо на этапе компиляции, либо во время выполнения процесс должен быть прерван в тот момент когда программа выходит за рамки дозволенного в языке.
А как быть, скажем с многопоточностью? Рушить все остальные 100500 параллельно выполняющиеся потоки? :-)
Короче, без Annex'ов не обойтись :-)
-
Возможно Вирту следовало в начале репорта написать:
"Что не определено явно, то запрещено" ;)
-
А как быть, скажем с многопоточностью? Рушить все остальные 100500 параллельно выполняющиеся потоки? :-)
А Вирт умный... у него нет многопоточности :P
-
А как быть, скажем с многопоточностью? Рушить все остальные 100500 параллельно выполняющиеся потоки? :-)
А Вирт умный... у него нет многопоточности :P
вот по этому он и не написал - Что не определено явно, то запрещено :D... что бы заведомо не ограничивать возможную реализацию