rezident (30.08.2012 00:00, просмотров: 132) ответил Ксения на Исключение проявилось на ПК не из-за C++, а из-за способности аппаратно обрабатывать исключения у процессоров семейства x86. Языки же - дело десятое, они лишь ловят соотвествующее прерывание и как-то это событие обрабатывают.-
- #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)