rezident (29.08.2012 22:36, просмотров: 138) ответил fk0 на Никак. Если там плавучка, то должен быть inf или nan (0/0), а не -1. В принципе может быть удобно забыть о исключениях и судить только по нечислам в конечном результате.-
- На MSP функции деления для int и long разные, имхо, при целочисленных операциях проще и надежнее проверку операндов перед операциями - это основа надежных вычислений. - Хитрый Китаец(30.08.2012 11:47)
- Угу. Уже перелопачиваем исходники. - rezident(30.08.2012 12:17)
- Или куском своего исходника исключить ситуации приводящие к появлению нуля. - PlainUser(30.08.2012 08:06)
- Нуль появляется внутри чужого исходника. Мне только результат вычислений доступен. - rezident(30.08.2012 11:44)
- Ну если он получает входные данные от какого-то железа сам то конечно.Надо вставлять проверки.Плодить говнокод с исключениями не стоит. - PlainUser(30.08.2012 12:26)
- Да, именно так, сам от железа. - rezident(30.08.2012 12:45)
- Ну если он получает входные данные от какого-то железа сам то конечно.Надо вставлять проверки.Плодить говнокод с исключениями не стоит. - PlainUser(30.08.2012 12:26)
- Нуль появляется внутри чужого исходника. Мне только результат вычислений доступен. - rezident(30.08.2012 11:44)
- а если так? x / (float)y - quarry(30.08.2012 00:08)
- Компилировать в режиме C++ и переопределить оператор деления? - SciFi(29.08.2012 22:47)
- Исключение проявилось на ПК не из-за C++, а из-за способности аппаратно обрабатывать исключения у процессоров семейства x86. Языки же - дело десятое, они лишь ловят соотвествующее прерывание и как-то это событие обрабатывают. - Ксения(29.08.2012 23:46)
- Какое-либо прерывание организовать не большая проблема. Вопрос в том, как библиотечная функция сможет его (прерывание) вызвать? - rezident(30.08.2012 00:00)
- #include <signal.h> int div(int x, int y) { if (!y) raise(SIGFPE); return x/y; } -- соответственно через signal(SIGFPE, handler...) перехватывать, и делать, например longjmp вместо throw и setjmp ранее вместо catch. Именно прерывание не нужно. fk0(41 знак., 30.08.2012 00:10)
- Я это делаю не средствами языка/среды, а средствами Windows-API, которые позволяют обрабатывать такие ситуации: Ксения(1530 знак., 30.08.2012 14:20 - 14:26)
- Микрософт изобрёл свой signal, свой longjmp и всю свою C-библиотеку. Замечательно. Но зачем??? - fk0(30.08.2012 15:43)
- Затем, что с некоторых пор Windows - многозадачная система. Поэтому дать одной из задач доступ к обработчику исключений нельзя - порушится конфеденциальность. А так, через установку собственного хадлера, приложение получает только те исключения, Ксения(42 знак., 30.08.2012 17:29)
- Windows до сих пор не сильно многозадачная система если память одного процесса доступна другому. - fork(30.08.2012 23:02,
)
- Если оба процесса принадлежат одному и тому же приложению, то почему бы и нет? - Ксения(30.08.2012 23:19)
- Потому что так работает настоящая железная многозадачность. У вас есть один и тот же код и он работает параллельно на разных наборах данных. - thread(31.08.2012 00:16, )
- "Потоки существуют в одном контексте процесса, поэтому переключение между потоками происходит очень быстро, а вопросы безопасности не принимаются во внимание" => - Ксения(31.08.2012 00:31, ссылка)
- В многозадачных системах память одного процесса недоступна другому на уровне пользователя. - restrict(31.08.2012 01:02, )
- Так это же крайне неудобно! Например, я работаю с матрицей или изображением. Ради повышения скорости могу обработку четных рядов нагрузить на один поток, а нечетные ряды на другой. Или как-то еще по-другому поделить работу, зная, что потоки скорее Ксения(488 знак., 31.08.2012 02:00)
- В unix потоки это те же процессы, но с общей памятью. Так что вам будет очень удобно. Беда в том, что в Windows процессы это местами недопроцессы и Windows до сих пор строго говоря немногозадачна. - pity(31.08.2012 02:22, )
- Ну и слава богу, что немногозадачна в строгом смысле. Огораживание каждой задачи/процесса бетонной стеной создает больше проблем для программиста, чем реально делает работу устойчивей. - Ксения(31.08.2012 12:54)
- Разве в Windows приложения не огорожены друг от друга бетонной стеной? В Unix приложение суть процесс. Зачем добавлять новые сущности когда можно один раз реализовать fork. По поводу надежности посмотрите сколько суперкомпьютеров из топ500 exec(110 знак., 31.08.2012 16:57, )
- Linux is obsolete! - fk0(31.08.2012 17:21)
- Поживёт ещё пока Microsoft PIC не реализовал. - PIE(31.08.2012 23:31, )
- Поживёт ещё пока Microsoft PIC не реализовал. - PIE(31.08.2012 23:31,
- Linux is obsolete! - fk0(31.08.2012 17:21)
- Только в андроиде, например, огораживание ещё более серьёзное. К чему бы то? - fk0(31.08.2012 13:31)
- Разве в Windows приложения не огорожены друг от друга бетонной стеной? В Unix приложение суть процесс. Зачем добавлять новые сущности когда можно один раз реализовать fork. По поводу надежности посмотрите сколько суперкомпьютеров из топ500 exec(110 знак., 31.08.2012 16:57,
- Ну и слава богу, что немногозадачна в строгом смысле. Огораживание каждой задачи/процесса бетонной стеной создает больше проблем для программиста, чем реально делает работу устойчивей. - Ксения(31.08.2012 12:54)
- В unix потоки это те же процессы, но с общей памятью. Так что вам будет очень удобно. Беда в том, что в Windows процессы это местами недопроцессы и Windows до сих пор строго говоря немногозадачна. - pity(31.08.2012 02:22,
- Так это же крайне неудобно! Например, я работаю с матрицей или изображением. Ради повышения скорости могу обработку четных рядов нагрузить на один поток, а нечетные ряды на другой. Или как-то еще по-другому поделить работу, зная, что потоки скорее Ксения(488 знак., 31.08.2012 02:00)
- В многозадачных системах память одного процесса недоступна другому на уровне пользователя. - restrict(31.08.2012 01:02,
- "Потоки существуют в одном контексте процесса, поэтому переключение между потоками происходит очень быстро, а вопросы безопасности не принимаются во внимание" => - Ксения(31.08.2012 00:31, ссылка)
- Потому что так работает настоящая железная многозадачность. У вас есть один и тот же код и он работает параллельно на разных наборах данных. - thread(31.08.2012 00:16,
- Если оба процесса принадлежат одному и тому же приложению, то почему бы и нет? - Ксения(30.08.2012 23:19)
- Не надо путать сапоги и пряники. Unix тоже многозадачная система, и ANSI/ISO C тоже предполагает программы в многозадачной системе. И сигналы у каждой задачи свои. Ваши "хендлеры" и "исключения" ничем принципиально не отличаются от сигналов из fk0(221 знак., 30.08.2012 18:26)
- Windows до сих пор не сильно многозадачная система если память одного процесса доступна другому. - fork(30.08.2012 23:02,
- Затем, что с некоторых пор Windows - многозадачная система. Поэтому дать одной из задач доступ к обработчику исключений нельзя - порушится конфеденциальность. А так, через установку собственного хадлера, приложение получает только те исключения, Ксения(42 знак., 30.08.2012 17:29)
- :))) -> - SciFi(30.08.2012 14:26, ссылка)
- Микрософт изобрёл свой signal, свой longjmp и всю свою C-библиотеку. Замечательно. Но зачем??? - fk0(30.08.2012 15:43)
- Я это делаю не средствами языка/среды, а средствами Windows-API, которые позволяют обрабатывать такие ситуации: Ксения(1530 знак., 30.08.2012 14:20 - 14:26)
- #include <signal.h> int div(int x, int y) { if (!y) raise(SIGFPE); return x/y; } -- соответственно через signal(SIGFPE, handler...) перехватывать, и делать, например longjmp вместо throw и setjmp ранее вместо catch. Именно прерывание не нужно. fk0(41 знак., 30.08.2012 00:10)
- Какое-либо прерывание организовать не большая проблема. Вопрос в том, как библиотечная функция сможет его (прерывание) вызвать? - rezident(30.08.2012 00:00)
- Во-первых, я C++ совершенно не знаю. Во-вторых, а как это поможет? Исключение появится что ли? - rezident(29.08.2012 22:51)
- Перегрузить операторы для скалярных типов вроде как нельзя, только для классов. - fk0(30.08.2012 00:15)
- Я тоже не особо знаю. Ради такого случая можно немного и подучить. Если не ошибаюсь, переопределённый оператор может делать вообще всё, в том числе и проверять операнды перед делением. А ещё throw/catch могут пригодиться. - SciFi(29.08.2012 23:05)
- Ну уж нафиг такие сложности! Проще по тексту исходников "вручную" проверки операндов понавставлять. - rezident(29.08.2012 23:36)
- Если платформа не имеет аппаратного деления, то надёжнее все функции деления завернуть в обёртки. Только их не одна, может быть с десяток (grep div по листингу). А если имеет аппаратное деление, то обычно умеет прерывание по факту. - fk0(30.08.2012 00:14)
- Аппаратный только умножитель. MSP430 это RISC, а не CISC. - rezident(30.08.2012 00:24)
- Если платформа не имеет аппаратного деления, то надёжнее все функции деления завернуть в обёртки. Только их не одна, может быть с десяток (grep div по листингу). А если имеет аппаратное деление, то обычно умеет прерывание по факту. - fk0(30.08.2012 00:14)
- Ну уж нафиг такие сложности! Проще по тексту исходников "вручную" проверки операндов понавставлять. - rezident(29.08.2012 23:36)
- Исключение проявилось на ПК не из-за C++, а из-за способности аппаратно обрабатывать исключения у процессоров семейства x86. Языки же - дело десятое, они лишь ловят соотвествующее прерывание и как-то это событие обрабатывают. - Ксения(29.08.2012 23:46)
- На MSP функции деления для int и long разные, имхо, при целочисленных операциях проще и надежнее проверку операндов перед операциями - это основа надежных вычислений. - Хитрый Китаец(30.08.2012 11:47)