Здравствуйте, velkin, Вы писали:
V>Это очень древняя тема, например, программирование COM/DCOM.
V>Роджерсон Дейл: Основы COM; 6. HRESULT GUID, Реестр и другие детали
V>[q]
V>HRESULT
COM, кстати, отличный пример того, как делать не надо. всех причастных к его разработке стоило бы отправить копать Беломорканал за вредительство

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

__>Здравствуйте, _hum_, Вы писали:
__>>Image: f3951f298dd5dad1cf532ab7e6e7c5b9.png
__>>
__>что это за картинка?
__>у математики много разделов. единственный раздел, который оперирует с бесконечностями это ТФКП, но там есть свои собственные заморочки и a там комплексная и на плоскости, поэтому минус бесконечности, например, есчли не ошибаюсь, нет

wiki/Extended_real_number_line

ваша ошибка в том, что вы считаете себя здесь единственным знакомым с высшей математикой

__>с точки зрения матана бесконечность — процесс

нет. в матане есть два понятия — потенциальная (и это действительно бесконечный процесс) и абсолютная (предел) бесконечности

__>и деля на бесконечность можно получить в итоге процесса что угодно, хоть 42. сама бесконечно не может принадлежать ни какому из множества чисел, чтобы не ломать кучу аксиом и теорем.

нельзя, поскольку как lim a/n, n -> +oo, так и a/+oo — оба равны нулю.

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

речь не шла про кардинальные числа и ординалы высших порядков. речь шла про расширение числовой прямой

__>так что я понять не могу из какого раздела эта картинка. для решебника 8ого класса какой-то школы со своей программой?

первый курс, начала матанализа

__>>не отображение, а расчет отображаемого времени (сколько времени прошло с момента начала вентиляции, например) а вообще, вам как математику вроде бы должен быть близок принцип аналогии. нет?
__>была история одна известная про чела, который писал софт для ренгтеновского, по-моему аппарата. он bool когда хотел в истину взвести, просто его инкрементил. ну, хацкер, чего с него взять. из-за этого в 1 из 256 случаев внизапна bool становился false после инкремента и куча человек получила переоблучение.

к чему это?

__>нормальный софт должен делать abort() когда у тебя вдруг bool стал равен 2. ненормальный — может продолжать работать, пытаясь сохранить хорошую мину при плохой игре.
__>в случае же какого-то аппарата вентиляции легких или еще чего-то обычно ставят watchdog, который перезагружает софт при его падении или отсуствии отклика. или же можно переключиться на резервное устройство. может, текущее просто перегрелось. софт, который не падает и не виснет, а продолжает что-то там делать непонятное, неизвестное и малопредсказуемое, например, вдруг увеличивает или уменьшает скорости вентиляции в три раза, просто не нужен.

мды...

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

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

__>>В с++ в направлении усовершенствования исключений идет заметное движение. А как вообще в мире и в с++ в частности обстоит дело с развитием альтернатив исключениям (теми же кодами возвратов ошибок)?

V>Это очень древняя тема, например, программирование COM/DCOM.
[...]
V>И так далее.

ну так я и хотел узнать, во что она в 21 веке эволюционировала

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

__>COM, кстати, отличный пример того, как делать не надо. всех причастных к его разработке стоило бы отправить копать Беломорканал за вредительство

Это да

И всё же заложенные идеи у майкрософт были хороши. Другое дело, что программировать всё это хозяйство очень тяжело. Реализация подкачала в том смысле, что была создана не для людей программистов. Впрочем CORBA тоже провалилась. С другой стороны данный пример можно вполне использовать для изучения принципов работы с возвратом кодов ошибок. Ведь по сути для этого нужен какой-нибудь большой известный фреймворк, в нашем случае ещё и на C++. В том же Qt есть другой подход к кодам ошибок, для примера, QSqlError. А вот если не брать известные фреймворки, то с таким же успехом можно выдумывать обработку ошибок самим.

Здравствуйте, _hum_, Вы писали:
__>ваша ошибка в том, что вы считаете себя здесь единственным знакомым с высшей математикой
я надеюсь, что тут вообще с ней все знакомы или по-крайней мере собираются познакомиться после окончания школы

__>нет. в матане есть два понятия — потенциальная (и это действительно бесконечный процесс) и абсолютная (предел) бесконечности
у нас разные курсы матана были.

__>нельзя, поскольку как lim a/n, n -> +oo, так и a/+oo — оба равны нулю.
а если а = n*42?
в матане рассмотрение пределов, когда у нас обе части дроби стремятся к нулю или бесконечности это же любимое дело, полматана этим занимается. просто провозгласить, что типа есть бесконечность и вот вам операции с ней это какая-то хрень по-моему.

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

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

__>ну так я и хотел узнать, во что она в 21 веке эволюционировала

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

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

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

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


__>>нет. в матане есть два понятия — потенциальная (и это действительно бесконечный процесс) и абсолютная (предел) бесконечности
__>у нас разные курсы матана были.

__>>нельзя, поскольку как lim a/n, n -> +oo, так и a/+oo — оба равны нулю.
__>а если а = n*42?

не может такого быть, поскольку в правой части у вас величина, зависящая от n, а в левой — константа (в противном случае бы писалось a(n) или a_n, вам ли как математику этого не знать)

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

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

вообще-то все используют, начиная с первого курса: в расширенной числовой прямой предел lim n, n->oo равен oo, а не "не существует", как в случае обычной прямой

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

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

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

__>>ну так я и хотел узнать, во что она в 21 веке эволюционировала

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

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

на самом деле идеи интересные есть. те же монады (но я пока с ними не разобрался )

Здравствуйте, _hum_, Вы писали:
__> вообще-то все используют, начиная с первого курса: в расширенной числовой прямой предел lim n, n->oo равен oo, а не "не существует", как в случае обычной прямой
расширение-доопределение ф-ий для более широкого набора аргументов это, на самом деле круто. меня в свое сильно удивило расширение факториала гамма-функцией. это прямо мощь. но давайте мы попробуем доопределить, скажем 1/x в нуле, нашей, значит, бесконечностью. хорошо, какой? плюс или минус? получается, у нас плюс бесконечность равна минус, а, значит, мы переходим к комплексным числам вместо простых ламповых вещественных?
хорошо ли это? нет, это нехорошо. мы, не можем, например, их упорядочить между собой. нам придется пересмотреть все наши формулы со знаками меньше-больше, например. комплексные числа — это неудобные числа. вместо упрощения ситуации мы создаем себе геморрой на ровном месте.

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

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

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

__>расширение-доопределение ф-ий для более широкого набора аргументов это, на самом деле круто. меня в свое сильно удивило расширение факториала гамма-функцией. это прямо мощь. но давайте мы попробуем доопределить, скажем 1/x в нуле, нашей, значит, бесконечностью. хорошо, какой? плюс или минус? получается, у нас плюс бесконечность равна минус, а, значит, мы переходим к комплексным числам вместо простых ламповых вещественных?

Почему? Числовая окружность вместо прямой, но ещё не комплексные.

__>мне лично никогда не понятно было, к чему такое внимание к двухкомпонентным, которые почему-то именно на плоскости.

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

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

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

__> вообще-то все используют, начиная с первого курса: в расширенной числовой прямой предел lim n, n->oo равен oo, а не "не существует", как в случае обычной прямой

Не по сути, но по форме — у вас же наверняка у компьютера внутри юникод?
что мешает использовать символ "∞" (U+221E)?

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

__>>Здравствуйте, _hum_, Вы писали:
__>>>в этом случае даже если у вас произойдет деление на нуль, поток управления все равно продолжит течь, как ни в чем не бывало
__>>производя мусор
__>не мусор, а NaN значение

Придерусь — не NaN, а Inf. Это разные значения. В остальном согласен.

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

__>Здравствуйте, _hum_, Вы писали:
__>>не мусор, а NaN значение в математике же тоже так сделали — положили a/0 равным oo (бесконечности), что упростило написание кучи математических текстов (вместо того, чтобы каждый раз в тексте оговаривать "кроме нуля").
__>я мехмат закончил, это вы можете бабушке у подьезда заяснить, что a/0 равно бесконечности. в реальности конечно же ничего подобного в математике нет

Считайте это лёгким личным наездом, но именно тот факт, что это был мехмат, а не примат, кибернетика или что-то подобное, меня как раз и вводит в "смутные сомнения" о том, что Вы понимаете, что происходит и что должно быть.
Потому что обычно только после курса моделирования студент начинает понимать, что математика только тогда имеет смысл, когда моделирование сделано правильно.
Что натуральные числа это хорошо ровно настолько, насколько мы можем, например, считать все яблоки по 1 штуке, игнорируя, насколько одно больше, слаще или червивее другого (и даже оценить, какие погрешности получаются при таком игнорировании).
Почему старая шутка "стоящие часы полезнее, потому что хотя бы дважды в сутки показывают точное время" хороша только как средство для объяснения, что такое ложный парадокс, и должна стоять рядом с апориями Зенона.
И тэ дэ и тэ пэ.
Да, я тут однозначно на стороне прикладной математики. Можете кинуть цифровым камнем.

В этом смысле решение, чему равно 1/0 — вообще не существует, ∞ без знака, +∞ или ещё чему-то — просто выбор контекста для работы, и контекст, где это противоположное нулю значение на числовой окружности, не менее важен, чем тот, где значения не существует. Он просто другой.

__>>если петя забудет, то в случае с NaN — получит работающую программу, выдающую результатом NaN, что лучше, чем падение, поскольку программа может попутно еще делать какие-то важные действия, никак не связанные с последствиями исключительной ситуации (например, отображение времени на экране монитора никак не связано с управлением искусственной вентиляцией легких больного, и "валить систему" только потому, что при расчете времени произошло деление на нуль — кощунство )
__>а зач6м Петя свалил в один процесс отображение времени на экране и вентиляцию легких? он у нас дурачок-с?

Это, вообще-то, одна и та же установка, и часто один и тот же процессор. Который может, например, уметь плавучку по стандарту, но не иметь защиты памяти и режима супервизора. А что вы предлагаете? Вызывать аппаратный ресет по переполнению?
Почитайте IEEE754, его умные люди делали и они не зря ввели маски исключений и битовые поля сработавших замаскированных ошибок, средства управления ими (чтение, сброс)...

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

"Новые языки" тут ни при чём. Возведение 1e200 в double в квадрат выдаст +Inf даже в Фортране, если платформа по IEEE754 и режим округления не трогали. Странности реализации JS с этим никак не связаны, там много другого хитрого.
Я всё тоскую, что не сохранил скриншот, где номер банковской карточки выводился в виде 5.3762e+16 — удобный аргумент в некоторых спорах но опять же это number vs. string, а не float vs. integer.

__> удобно иметь Nan? удобно. но это в ущерб стиабильности работы. где нас это устраивает? в гуе, например, более-менее.

Повторяю: это обеспечить тривиально, если вызвать, в терминах языка Си, feenableexcept(FE_OVERFLOW|FE_DIVBYZERO). Сделайте — и первое же переполнение вызовет исключение (будет это SIGFPE, как по умолчанию в Unix, переведётся в SEH или как-то ещё передастся — это уже за пределами стандартов, но как-то будет). Для других языков не знаю, но в C#, наверно, checked покрывает эту тему.

__> хотя я бы предпочел все-таки в каком-то медицинском или финансовом гуе, чтобы инфа все-таки были или 100% корректной или никакой, а не "корректной, но не всегда"

Оно так и будет. Просто где-то будет исключение сразу, а где-то надо самому проверить, что NaN не возник в данных и/или не перепутан с реальным значением, и проверки сделаны правильно (например, с плавучкой нельзя автоматически считать, что если a>b, то b<a, потому что есть четвёртый случай — несравнимость).

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

__>>с точки зрения матана бесконечность — процесс
__>нет. в матане есть два понятия — потенциальная (и это действительно бесконечный процесс) и абсолютная (предел) бесконечности

s/абсолютная/актуальная/

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

EP>>Есть некий симбиоз возвращаемых значений и исключений — expected&lt;T&gt;
__>выглядит страшнова-то.. а вот указанный boost::optional<T> уже "ближе", но все равно еще не то...

От Optional отличие только в том, что внутри могут хранится разные исключения, а не только bad_optional_access.

__>>>Или каких-нибудь замыканий (монад?), наподобие добавления к множеству возможных числовых результатов операций значения NaN, которое выводит деление на нуль из области исключительных ситуаций, и тем самым позволяет избавиться от уймы проверок на промежуточных этапах?
EP>>Исключения это и есть монада, которая позволяет "избавиться от уймы проверок на промежуточных этапах"
__>мм... может, я неправильно выразился. я имел ввиду подход, когда вместо того, чтобы считать a/0 неопределенностью, просто расширяют тип вещественных чисел за счет введения значения NaN, для которого полагается
__> a @ NaN -> NaN
__> NaN @ NaN -> NaN
__>(здесь @ — любая операция)

Это аппликативный функтор, а не монада.

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

Монада в этом контексте как раз и отличается от аппликативного функтора тем что может прервать поток управления, так как весь этот поток управления протекает через неё.

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

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

__>В с++ в направлении усовершенствования исключений идет заметное движение. А как вообще в мире и в с++ в частности обстоит дело с развитием альтернатив исключениям (теми же кодами возвратов ошибок)?
Да дело не в инструменте как таковом.
Если ты для каждого состояния системы рассмотришь не только рабочие состояния, но и аварийные...
Если ты рассклассифицируешь эти аварийные состояния по степени тяжести...
Если ты спроектируешь реакцию системы в каждом классе аварийных состояний...
Если ты напишешь все сообщения для аварийных состояний...
Тогда можно посмотреть в сторону инструмента — как это все реализовать.
ИМХО в этом случае аппарата исключений вполне достаточно.
А в системах реального времени — коды возврата (если средство разработки для этого подходящее)

Здравствуйте, netch80, Вы писали:
N>В этом смысле решение, чему равно 1/0 — вообще не существует, ∞ без знака, +∞ или ещё чему-то — просто выбор контекста для работы, и контекст, где это противоположное нулю значение на числовой окружности, не менее важен, чем тот, где значения не существует. Он просто другой.
если вы когда-нибудь брали какой-нибудь большой интеграл или пытаись доказать хитрую теорему, то вы знаете, что маааленькая ошибочка где-то посредине рассуждений аннулирует все рассуждения.

вы не можете дополнить вещественные числа двумя бесконечностями, так как, например, дополнение 1/x в нуле противоречит определению ф-ии.
вы не можете дополнить вещественные числа одной бесконечностью и сохранить их упорядоченность, то есть не можете пользоваться другими свойствами вещ. чисел, так как inf < x < inf.
а еще, кстати, введение бесконечности противоречит определению нуля. поэтому в таких числах нуля быть не может. вы можете ввести свой ноль, но это будет другой ноль и вы должны пользоваться другим его обозначением.

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

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

у меня есть подозрения, что, по-аналогии, возможность проводить операции с nan тоже фундаментально абсурдны, как и факт иметь обьект в невалидном состоянии вообще. мы не можем иметь int имеющий одновременно и плюс и минус. мы не можем иметь букву, которая одновременно и а и б. мы не можем иметь строку ненулевой длины начинающейся с 0. мы не можем иметь bool, который одновременно true и false. то есть мы все это можем сделать, но все это будут обьекты в невалидном состоянии. и вместо того, чтобы писать код для каждого из таких случаев, нам было бы в сто раз удобнее не допускать такое состояние вообще. возникновение такого состояния — abort()

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

__>Здравствуйте, netch80, Вы писали:
N>>В этом смысле решение, чему равно 1/0 — вообще не существует, ∞ без знака, +∞ или ещё чему-то — просто выбор контекста для работы, и контекст, где это противоположное нулю значение на числовой окружности, не менее важен, чем тот, где значения не существует. Он просто другой.
__>если вы когда-нибудь брали какой-нибудь большой интеграл или пытаись доказать хитрую теорему, то вы знаете, что маааленькая ошибочка где-то посредине рассуждений аннулирует все рассуждения.

Да. Но при чём тут это? Если посреди вычислений возникнет Inf (которое в IEEE754 означает не бесконечность вообще, а "значение, не поместившееся в стандартные размеры, или его потомок в операциях"), то, если это Inf не будет скомпенсировано тем, что где-то оно вообще неважно, так и останется Inf, то есть признаком "когда-то было переполнение". Аналогично для NaN. У вас не возникнет неожиданно корректно выглядящего, но неправильного значения, только за счёт того, что где-то раньше были Inf или NaN.

__>вы не можете дополнить вещественные числа двумя бесконечностями, так как, например, дополнение 1/x в нуле противоречит определению ф-ии.

Мнэээ... подробнее, пожалуйста. Функция, насколько я помню, это отображение, которое для каждого прообраза из области определения даёт один и только один образ из области значений. Так?
И каким же образом это дополнение противоречит определению функции, если для f(x)=1/x
1) мы добавляем значения 0 и ∞ в обе области (определения и значения);
2) функция переводит их друг в друга;
3) значение функции для любого другого значения из ℝ этим не меняется
?

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

А кто говорил про такую же линейную упорядочённость, и что она в этом случае должна сохраняться? Естественно, я не требую её сохранения (в том же виде) в случае включения ∞.

__> то есть не можете пользоваться другими свойствами вещ. чисел, так как inf < x < inf.

Могу. С соответствующими уточнениями. Вас же не приводит в ступор, например, то, что для комплексных чисел уже нельзя определить стандартные сравнения типа "меньше"? Или что квадратный корень ℝ->ℝ почему-то в друг при выходе в ℝ⁻ перестаёт работать? Почему там могут возникать уточнения, а тут — нет?

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

Будут правильными. Важна внутренняя согласованность понятий и концепций, а она в описываемом случае есть.

__>у меня есть подозрения, что, по-аналогии, возможность проводить операции с nan тоже фундаментально абсурдны, как и факт иметь обьект в невалидном состоянии вообще.

Это просто другой подход. Можно признак невалидности держать отдельно, а можно — встроенно. Второй подход очень распространён из-за его банального удобства. Например, указатель, равный NULL (nullptr, nil и т.д.) В большинстве реализаций внутри NULL — число 0. Это значит, что вы не можете для каких-то сурово системных целей читать/писать память по адресу 0; но вы в таком случае не можете использовать логику, что NULL означает признак невалидности указателя. Или open(), которая выдаёт в int дескриптор файла (если >=0) или признак ошибки (-1), а не отдельный флаг ошибки. Дотнетовский Nullable<T> в этом смысле — удобная контейнеризация отдельного признака невалидности, пригодная ко всему, но удорожанием. В IEEE754 сделали встроенный.

__> мы не можем иметь int имеющий одновременно и плюс и минус. мы не можем иметь букву, которая одновременно и а и б. мы не можем иметь строку ненулевой длины начинающейся с 0.

C-строка, начинающаяся с NUL? Прошу быть корректнее в терминах. А то всяким std::string это никто не запрещает.

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

Не вижу никаких причин утверждать про "удобнее", тем более "в сто раз", и вижу противоположные тенденции, как на своём опыте, так и на опыте всей отрасли (выражающемся в создании значений типа NULL и NaN, возврате -1 по ошибке, и т.п.).
И пример с bool некорректен, если вспомнить fuzzy logic (нечёткую логику) и её признаки вероятности какого-то значения.
И "этот int положительный с вероятностью 69% и отрицательный с 26%" тоже возможно, если этого требует модель.

__> возникновение такого состояния — abort()

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

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

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

__>>>Здравствуйте, _hum_, Вы писали:
__>>>>в этом случае даже если у вас произойдет деление на нуль, поток управления все равно продолжит течь, как ни в чем не бывало
__>>>производя мусор
__>>не мусор, а NaN значение

N>Придерусь — не NaN, а Inf. Это разные значения. В остальном согласен.

ого. не знал, что они ввели еще и бесконечности. здорово. только почему-то не нахожу инфу по их поведению (предполагаею, что наверное полностью соответствующее математическому определению + выход в qNaN в случае математической неопределенности. так?)

__>>>с точки зрения матана бесконечность — процесс
__>>нет. в матане есть два понятия — потенциальная (и это действительно бесконечный процесс) и абсолютная (предел) бесконечности

N>s/абсолютная/актуальная/

да, конечно

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

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

EP>>>Есть некий симбиоз возвращаемых значений и исключений — expected&lt;T&gt;
__>>выглядит страшнова-то.. а вот указанный boost::optional<T> уже "ближе", но все равно еще не то...

EP>От Optional отличие только в том, что внутри могут хранится разные исключения, а не только bad_optional_access.

в boost::optional<T> тоже зашит эксепшн? ну тогда он мне тоже не нравится мне нравится сама идея — возможность самому расширять любой тип значением undefined, чтобы замкнуть хотя бы какие-то операции


__>>>>Или каких-нибудь замыканий (монад?), наподобие добавления к множеству возможных числовых результатов операций значения NaN, которое выводит деление на нуль из области исключительных ситуаций, и тем самым позволяет избавиться от уймы проверок на промежуточных этапах?
EP>>>Исключения это и есть монада, которая позволяет "избавиться от уймы проверок на промежуточных этапах"
__>>мм... может, я неправильно выразился. я имел ввиду подход, когда вместо того, чтобы считать a/0 неопределенностью, просто расширяют тип вещественных чисел за счет введения значения NaN, для которого полагается
__>> a @ NaN -> NaN
__>> NaN @ NaN -> NaN
__>>(здесь @ — любая операция)

EP>Это аппликативный функтор, а не монада.

а я думал, это что-то из разряда хаскелловской монады Maybe

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

EP>Монада в этом контексте как раз и отличается от аппликативного функтора тем что может прервать поток управления, так как весь этот поток управления протекает через неё.

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

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

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

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

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