[c#] .net 2003 NaN
man checked имхо
хотя при делении на 0 и так вроде Exception летит 
если не ошибаюсь, просто так летит при работе с целыми числами. NaN присваивается при работе с числами с плавающей точкой. Так что ман checked
Чота вы лохи оба.
The checked keyword is used to explicitly enable overflow-checking for integral-type arithmetic operations and conversions.
Я тоже хотел написать man checked, но потом последовал этому невысказанному совету и ничего не написал.
The checked keyword is used to explicitly enable overflow-checking for integral-type arithmetic operations and conversions.
Я тоже хотел написать man checked, но потом последовал этому невысказанному совету и ничего не написал.
вот именно
вопрос остается открытым
вопрос остается открытым
только через native: _control87, _controlfp, __control87_2 и т.д.
в мсдне написано, что это для с++ ...
А у Darkgreya - что это native.
что есть native?
native есть импортированный из соответствующей библиотеки при помощи кодового слова extern и атрибута DllImport.
в твоем предложении не хватает существительного к прилагательному импортированный
Посмотри в опциях компилятора - скорее всего это можно настраивать там.
ой =)
Импортированный метод! То есть функция! Читай хелп по DllImportAttribute и по тем функциям, названия которых сказал ДаркГрей.
Импортированный метод! То есть функция! Читай хелп по DllImportAttribute и по тем функциям, названия которых сказал ДаркГрей.
а из какой длл-ки вытаскивать ?
Может, dll придётся писать самому.
имхо, если нет совсем серьезных оснований - то лучше забить.
т.к. кроме вызова этих функций - остается еще очень большая проблема - как и кто будет полученные исключения сопроцессора транслировать в исключения .net-а.
т.к. кроме вызова этих функций - остается еще очень большая проблема - как и кто будет полученные исключения сопроцессора транслировать в исключения .net-а.
как и кто будет полученные исключения сопроцессора транслировать в исключения .net-а.Проблемы никакой - интероп и будет. Единственное что - будут проблемы с определением того, какое именно исключение произошло. Плюс, возможно, оно будет тормозить.
> Проблемы никакой - интероп и будет.
а JIT на тебя не обидится, что в глубине уже сильно unmanaged-кода - вдруг появляется - .net вставка?
ps
как минимум же остается та же самая проблема, что и для C++, что если в коде только машинные исключения - то блоки перехвата исключения - не создаются.
а JIT на тебя не обидится, что в глубине уже сильно unmanaged-кода - вдруг появляется - .net вставка?
ps
как минимум же остается та же самая проблема, что и для C++, что если в коде только машинные исключения - то блоки перехвата исключения - не создаются.
а JIT на тебя не обидится, что в глубине уже сильно unmanaged-кода - вдруг появляется - .net вставка?Ээээ что? В какой глубине? Наоборот, из вполне managed кода "a = b/c;" прилетит unmanaged исключение.
дополнение еще посмотри.
> Ээээ что? В какой глубине?
смысл в том, что managed код после JIT-а превращается в обычный native-код, который уже живет по своим правилам (соглашения по регистрам, сохранению контекстов, вызовов функций и т.д.).
в итоге получается, что в середине native-кода, причем не ожидаемо для jit-а - вдруг появляется другой .net-код - который живет чуть по своим правилам.
зы
или вот такая проблема:
данный код
jit имеет право превратить в
что в итоге приведет - к испорченным данным, при генерации исключения внутри выражения b/c
для деления int-ов ситуация иная - там jit потенциально знает, что данная операция может генерить исключение.
> Ээээ что? В какой глубине?
смысл в том, что managed код после JIT-а превращается в обычный native-код, который уже живет по своим правилам (соглашения по регистрам, сохранению контекстов, вызовов функций и т.д.).
в итоге получается, что в середине native-кода, причем не ожидаемо для jit-а - вдруг появляется другой .net-код - который живет чуть по своим правилам.
зы
или вот такая проблема:
данный код
float a = b/c;
this.obj = new Class(data);
jit имеет право превратить в
this.obj = malloc;
float a = b/c;
obj.Class constructor;
что в итоге приведет - к испорченным данным, при генерации исключения внутри выражения b/c
для деления int-ов ситуация иная - там jit потенциально знает, что данная операция может генерить исключение.
Я не знаю, на самом деле.
Когда-то давно я читал про SEH и его взаимодействие с CLR и вынес оттуда ощущение, что CLR является надстройкой над SEH и вполне обратно совместимо, то есть SEH-исключения прекрасно ловит. Но это не более чем ощущение, потому что на самом деле там всё жутко сложно.
Я думаю, только непосредственная проверка позволит получить точный ответ.
Да, кстати, ещё не очень понятно, зачем автору нужна такая фигня. Если у него где-нибудь в вычислениях появился NaN или Inf, то он уже никогда не исчезнет, и нужно будет написать одну проверку типа if (double.IsInfinity(result)||double.IsNan(result). Если ему интересно узнать - где именно, то проще ручками вставить туда аналогичную проверку, чем окружать трай-котчем.
Когда-то давно я читал про SEH и его взаимодействие с CLR и вынес оттуда ощущение, что CLR является надстройкой над SEH и вполне обратно совместимо, то есть SEH-исключения прекрасно ловит. Но это не более чем ощущение, потому что на самом деле там всё жутко сложно.
Я думаю, только непосредственная проверка позволит получить точный ответ.
Да, кстати, ещё не очень понятно, зачем автору нужна такая фигня. Если у него где-нибудь в вычислениях появился NaN или Inf, то он уже никогда не исчезнет, и нужно будет написать одну проверку типа if (double.IsInfinity(result)||double.IsNan(result). Если ему интересно узнать - где именно, то проще ручками вставить туда аналогичную проверку, чем окружать трай-котчем.
А, понял.
Хохо.
Да, пожалуй ты прав.
Хохо.
Да, пожалуй ты прав.
ну я уже забил, вызвать функцию у меня получилось, а вот добиться чего нить хорошего от его вызова не очень....
меня как то ломает думать, куда ставить проверки на НаН (не ставить же их после каждой операции и даже если их поставить довольно часто, все равно потом точно не угадаешь где эта лажа происходит (тута у меня по 10^7 итераций, ставить брейкпоинты - не тема)
меня как то ломает думать, куда ставить проверки на НаН (не ставить же их после каждой операции и даже если их поставить довольно часто, все равно потом точно не угадаешь где эта лажа происходит (тута у меня по 10^7 итераций, ставить брейкпоинты - не тема)
меня как то ломает думать, куда ставить проверки на НаН (не ставить же их после каждой операции и даже если их поставить довольно часто, все равно потом точно не угадаешь где эта лажа происходит (тута у меня по 10^7 итераций, ставить брейкпоинты - не тема)если не хочешь думать, то можно написать обертку double-а, с нужным тебе поведением. Правда потеря производительности... насколько это критично оценивать тебе
К сожалению, под .нет лёгкую обёрту дабла запаришься писать - все ValueType sealed. Но вообще можно.
Оставить комментарий
Vodnik
как сделать чтобы при делении на ноль и пр. вылетал Exception, а не присваиволось NaN или +-Infinity?