Здравствуйте, uncommon, Вы писали:

U>Товарищ Александреску опять по своему обыкновению придумал фигню, которую никто никогда не будет использовать. Даже он сам. Expected<T> завязан на make_exception_ptr:

Смотри что покажу — std::make_exception_ptr.

Там сказано "as if", но на самом деле исключение не выбрасывается из экономии.

Здравствуйте, __kot2, Вы писали:

__>если вы допускаете Nan, то, например, даже две корректные реализации поиска максимального элемента массива могут дать разные результаты. вам нужны nan-proof версии всего когда, использующего сравнения < >
__>то же самое с сортировками

Глубокоуважаемый коллега забывает, что сравнение вещественных чисел на больше-меньше, кроме самого низкого уровня реализации, вообще является операцией очень сомнительной по смыслу. Если эти числа возникли из вычислений, то в большинстве случаев сравнение должно включать в себя оценку на абсолютную и относительную погрешность, и числа могут быть достаточно близки, чтобы для них "больше" или "меньше" стало недостаточно обооснованными. Если это что-то вроде входных данных статистики, то там или это уже решено (scipy, например, отрабатывает это из коробки), или NaN'ов просто не будет.

Если же вдруг кому-то такие безобразия (сравнение несравнимого) потребовались, то стандарт IEEE754 определяет понятие total ordering и соответствующие функции сравнения для таких случаев. В качестве "заката солнца вручную" при отсутствии таких средств в библиотеках можно постановить, что любой NaN больше определённого значения и равен другому NaN. Три строчки с перекуром.

__>при введении Nan вы либо откалываетесь от всех сравнений <, либо пишете проверку на nan перед каждым таким сравнением. стало сразу удобно, да? только школьник-жапоскриптер может испытывать удобства от наличия Nan, ваяя свой спагетти говнокод

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

Здравствуйте, _hum_, Вы писали:

__>нет, дело именно в инструментарии, потому как иногда из-за его отсутствия приходится пересматривать понятие "аварийность" (когда обрабатывать некритические ошибки становится настолько громозко, что проще сделать их критическими с вызовом abort()")

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

Но дальше можно разные ситуации рассматривать как "ошибки", как-то их классифицировать, например на "критические" и нет, и дальше проектировать какие-то реакции н ситуацию.

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

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

Здравствуйте, Evgeny.Panasyuk, Вы писали:

__>>ну как же не замусоренную, если вам придется продумывать "а что будет, если вот именно в этом месте поток исполнения прервется и пойдет по совсем другому пути" и вставлять предусматривающий такой ход код?

EP>Если речь идёт про Exception safety, то на C++ обычно всё что требуется для basic guarantee было бы и без исключений.
IMHO, это не правда...
Ну, например, если мы отдаём куда-то два владеющих указателя, то могли бы написать так:

takeOwnership( new A1, new A2 );

Но из-за basic guarantee не пишем... Пишем что-то более хитрое...
Кстати, если таки считать, что исключение кидают что бы аккуратно перезапустить программу, то память можно терять...

EP>Если же речь про strong guarantee, которую часто ассоциируют с транзакционностью — то её придётся "продумывать" в любом языке
Про strong guarantee разговаривать вообще бессмысленно, IMHO, так как это свойство кода неверефицируемо.
Если нужны гарантии устойчивости такого уровня, то надо как-то совсем иначе проектировать программу

EP>Почему эта мифическая угроза заставляет ловить везде исключения, но при этом не заставляет проверять NaN-ы?
+100500

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

Здравствуйте, BulatZiganshin, Вы писали:


BZ>представь себе что скажем ты на gpu обрабатываешь триллион точек в секунду. и те точки у которых с данными что-то не срослось — надо просто игнорировать. какие уж там исключения, даже на if'ы времени не хватит...

А ядра для какого GPU можно на с++ с исключениями писать?

Здравствуйте, netch80, Вы писали:

__>>то же самое с сортировками

N>Глубокоуважаемый коллега забывает, что сравнение вещественных чисел на больше-меньше, кроме самого низкого уровня реализации, вообще является операцией очень сомнительной по смыслу.

А если мне, например, надо отсортировать объекты по вычислимому вещественному параметру?
Скажем я программирую А*, и оценка остатка пути вещественная, то я могу варианты продолжения сортировать?

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

Можно показать это на примере А* выше?

Здравствуйте, Erop, Вы писали:

__>>>то же самое с сортировками

N>>Глубокоуважаемый коллега забывает, что сравнение вещественных чисел на больше-меньше, кроме самого низкого уровня реализации, вообще является операцией очень сомнительной по смыслу.
E>А если мне, например, надо отсортировать объекты по вычислимому вещественному параметру?
E>Скажем я программирую А*, и оценка остатка пути вещественная, то я могу варианты продолжения сортировать?

Да, если ты уверен, что на входе алгоритма A* не будет NaN'ов, и потому что в таком случае его операции сложения не могут дать такое значение (у тебя же нет отрицательных весов путей? Тогда операция типа +∞ + -∞ невозможна). Также ты тогда знаешь, что погрешности вычисления тебе несущественны (если один путь даст 17.234987498237, а другой 17.234987498238, то тебе нет причин для строго предпочтения второго). Но это ты всё знаешь по сути своих действий, и потому знаешь, что обычная сортировка с обычными сравнениями в таком случае допустима — как с точки зрения погрешностей, так и с точки зрения сравнимости значений.
Не все алгоритмы такие, и для каждого надо стараться явно доказать эту допустимость.

N>>Только школьник-жабоскриптер может думать, что сортировка вещественных без уточнения (см. выше) имеет какой-то смысл, и да, у него на выходе будет исключительно спагетти говнокод.
E>Можно показать это на примере А* выше?

Уже показал.

Здравствуйте, netch80, Вы писали:

N>Да, если ты уверен, что на входе алгоритма A* не будет NaN'ов, и потому что в таком случае его операции сложения не могут дать такое значение
А если эвристика где-то провалится?..
Мы же рассматриваем наны, как альтернативу исключениям?

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

N>>>Только школьник-жабоскриптер может думать, что сортировка вещественных без уточнения (см. выше) имеет какой-то смысл, и да, у него на выходе будет исключительно спагетти говнокод.
E>>Можно показать это на примере А* выше?

N>Уже показал.
Ты сказал, что "можешь если нанов не будет", а что будет, если эвристика в каком-то случае провалится, не показал...
Ну и сортировка вещественных -- довольно распространённая операция. Или, например, взятие медианы...

Здравствуйте, Erop, Вы писали:

N>>Да, если ты уверен, что на входе алгоритма A* не будет NaN'ов, и потому что в таком случае его операции сложения не могут дать такое значение
E>А если эвристика где-то провалится?..

"Будут два тоннеля" (c)
Или включай исключения, или будь готов, что эвристика провалится, или гарантируй, что не провалится. Кстати, почему сразу "эвристика", почему ты для данного алгоритма не подразумеваешь возможность гарантированного отсутствия NaN?

E>Мы же рассматриваем наны, как альтернативу исключениям?

Да, именно так и рассматриваем.

N>>Не все алгоритмы такие, и для каждого надо стараться явно доказать эту допустимость.
E>Ну я примерно про то же. И для сложной программы анализ того, где там что наны обобщённые наделают сколь угодно сложен...

Включай исключения. Или проверяй по завершению процесса флаги в fegetexcept().

N>>Уже показал.
E>Ты сказал, что "можешь если нанов не будет", а что будет, если эвристика в каком-то случае провалится, не показал...

Зависит от настроек и от алгоритмов. std::sort, например, у меня в случае нарушения предиката на сравнение зависал. А мог и abort() вызвать. Так что вдумчивое применение настроек из <fenv.h> — наше всё.

E>Ну и сортировка вещественных -- довольно распространённая операция. Или, например, взятие медианы...

Я про статистику уже сказал раньше, не вижу смысла повторяться.

Здравствуйте, netch80, Вы писали:

N>"Будут два тоннеля" (c)
N>Или включай исключения, или будь готов, что эвристика провалится, или гарантируй, что не провалится. Кстати, почему сразу "эвристика", почему ты для данного алгоритма не подразумеваешь возможность гарантированного отсутствия NaN?

Потому, что А* (я думал это общеизвестная классика, вроде алгоритма Дейкстры, если это не так, то я прошу прощения) — это поиск кратчайшего пути в графе, но более целенаправленный, чем алгоритм Дейкстры. В качестве оценки перспективности того или иного наравления перебора гипотез используется эвристическая оценка цены остатка пути. Например, евклидово расстояния по плоскости. Вот функцию вычисления этой оценки я и называю эвристикой...

N>Включай исключения. Или проверяй по завершению процесса флаги в fegetexcept().
Ну так о том и речь, что почти любой сложный алгоритм с нанами плохо совместим, он тупо может вовсе не сойтись никогда, как вариант, если предусловия из-за нанаов не соблюдаются... Так что fegetexcept можно никогда не проверить

N>Зависит от настроек и от алгоритмов. std::sort, например, у меня в случае нарушения предиката на сравнение зависал. А мог и abort() вызвать. Так что вдумчивое применение настроек из <fenv.h> — наше всё.
Так я про то и говорю, что исключения концептуально проще...

N>Я про статистику уже сказал раньше, не вижу смысла повторяться.
Статистика это не все вещественные. Вот А* чем тебе не жизненный пример?

Здравствуйте, Erop, Вы писали:

N>>"Будут два тоннеля" (c)
N>>Или включай исключения, или будь готов, что эвристика провалится, или гарантируй, что не провалится. Кстати, почему сразу "эвристика", почему ты для данного алгоритма не подразумеваешь возможность гарантированного отсутствия NaN?

E>Потому, что А* (я думал это общеизвестная классика, вроде алгоритма Дейкстры, если это не так, то я прошу прощения) — это поиск кратчайшего пути в графе, но более целенаправленный, чем алгоритм Дейкстры. В качестве оценки перспективности того или иного наравления перебора гипотез используется эвристическая оценка цены остатка пути. Например, евклидово расстояния по плоскости. Вот функцию вычисления этой оценки я и называю эвристикой...

Про A* я в общем помню, но я подумал, что эвристикой было названо предположение, что NaNов не будет.

N>>Включай исключения. Или проверяй по завершению процесса флаги в fegetexcept().
E>Ну так о том и речь, что почти любой сложный алгоритм с нанами плохо совместим, он тупо может вовсе не сойтись никогда, как вариант, если предусловия из-за нанаов не соблюдаются... Так что fegetexcept можно никогда не проверить

Любая реальная реализация должна иметь ограничение количества итераций. Ну а проблемы качественной реализации математики даже в объёме FMM уже показывают, что это нетривиально и требует умелого проектирования.

N>>Зависит от настроек и от алгоритмов. std::sort, например, у меня в случае нарушения предиката на сравнение зависал. А мог и abort() вызвать. Так что вдумчивое применение настроек из <fenv.h> — наше всё.
E>Так я про то и говорю, что исключения концептуально проще...

Так я и предлагаю оппонентам включать их сразу.

N>>Я про статистику уже сказал раньше, не вижу смысла повторяться.
E>Статистика это не все вещественные. Вот А* чем тебе не жизненный пример?

Я не говорю, что он не жизненный. (Наверняка у меня в навигаторе какая-то его разновидность.)

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, _hum_, Вы писали:

__>>>>мне нравится сама идея — возможность самому расширять любой тип значением undefined, чтобы замкнуть хотя бы какие-то операции
EP>>>Мне не нравится инфицирование всех выражений undefined'ом.
__>>почему "всех"? можно же дать программисту возможность выбора, в каких операциях может участвовать расширенный тип, а в каких нет (и на этапе компиляции это отслеживать).

EP>Всех в цепочке вычислений.

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

грубо говоря, это может выглядеть так

<блок вычислений без контроля ошибок>

//--- начало контролируемой цепочки
extended<float> a_ex = <входные данные в контролируемую цепочку>

<цепочка вычислений, в том числе вида if(1 == a_ex){<bla-bla>}; поскольку сравнение с неопределенным значением - валидная и допускаемая компилятором  операция >

//-- завершение контролируемой цепочки
if(extended<float>::id_proper_value(a_ex))
{
    if(a_ex < 10){<do...>};
}
else
{
   cout<<"invalid result";
};

__>>>>кроме того, одна и та же нештатная ситуация может быть критической в одном случае и некритической в другом. и если она может возникнуть, например, в функции f() которую вы используете в нескольких местах, то вам придется во всех местах использования ставить трай-кэтчи, замусоривая код,
EP>>>Почему же во всех местах использования? Только в тех, где это критично.
__>>ну, если вы где-то не поставите катч, то программа у вас повалится,

EP>Что значит "повалится"?

значит аварийно завершить работу.

__>>даже если в том месте исключение не будет для вас критичным.

EP>Так смысл исключений как раз в том, что их нельзя проигнорировать, и это правильный подход по-умолчанию.

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

EP>Когда же легко игнорировать, например при кодах возврата — то их систематически игнорируют

Автор: MTD
Дата: 21.02.13

.

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

__>>>>тогда как в случае с аналогом NaN такой необходимости не будет.
EP>>>Если в каком-то месте критично чтобы вызов f() прошёл нормально, вернув нормальный результат, то и в случае с NaN'ами придётся городить проверки
__>>да, но в том месте, где это некритично, проверки можно не ставить

EP>Там где некритично — пусть оно летит наверх по стэку.

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

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

EP>Не вижу в этом проблемы — поставь catch наверху стэка

врде, мы ж с этого и начали — я вам говорил, что даже там, где мне не нужны эти проверки, мне придется замусоривать код ими, а вы отвечали

EP>Вообще-то наоборот — с исключениями мы имеем обычную логику не замусоренную проверками и обработками.

__>>даже там, где вам это некритично.

EP>Дай определение "некритично".

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

__>>

__>>if(1 == f())
__>>{
__>>   do_something();
__>>}
__>>

__>>в случае с "NaN" никаких доп. проверок делать не нужно. в случае с эксепшеном обязательно надо ставить трай-катч

EP>Обычно нужно обрабатывать все граничные варианты.

не факт

EP>И не вижу проблемы с try-catch для случаев явного игнорирования, так как это очень редкий случай.

проблема все та же — загрязнение "найтивного" кода этими трай-кэтч-ужасами.

EP>Я вот вообще не припомню вот такой код:
EP>

EP>try{ action1(); } catch(...){ /*ignore*/ }
EP>try{ action2(); } catch(...){ /*ignore*/ }
EP>try{ action3(); } catch(...){ /*ignore*/ }
EP>

не совсем понял, в чем смысл данного кода


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

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, _hum_, Вы писали:

__>>нет, дело именно в инструментарии, потому как иногда из-за его отсутствия приходится пересматривать понятие "аварийность" (когда обрабатывать некритические ошибки становится настолько громозко, что проще сделать их критическими с вызовом abort()")

E>А что такое "некритические ошибки" в твоём понимании? И что такое "ошибки" вообще?

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

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


E>Вот я, например, встречал такое определение "исключительной ситуации", что это такая ситуация, которая не должна возникать при выполнении программ, и не позволяет продолжать выполнение.
E>Тут исключения более или менее в тему, вроде.

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

E>Но дальше можно разные ситуации рассматривать как "ошибки", как-то их классифицировать, например на "критические" и нет, и дальше проектировать какие-то реакции н ситуацию.

E>Вот в известном мне определении есть такой момент, что такая ситуация не должна возникать при выполнении программы. То есть что-то, не известно что, уже пошло не так. Так что ошибка уже не "некритическая"...
E>Но можно расширить, например так, что иногда мы знаем, что пошло не так, и можем откатить ситуацию и предложить пользователю совет, как обойти проблему. Нужны ли тогда исключения? Ну фиг его знает, можно спроектировать систему обработки таких ситуаций на исключениях, а можно и на чём-то другом. И там и так можно...

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

вот! хотелось бы, чтобы в языке это как-то все систематизировалось, унифицировалось, и под это был создан удобный инструментарий (объединение несколько потоков ошибок в один, удобная передача из функции и т.п.)