caxapa.ru :: Компилировать в режиме C++ и переопределить оператор деления?

SciFi (29.08.2012 22:47, просмотров: 129) ответил rezident на Все бы ничего, но у меня кусок чужого исходника, который нужно целиком имплантировать в программу. Деление на нуль заметили только когда этот кусок стали отлаживать на ПК в Builder-e - программа стала выпадать в исключение. При компиляции в

Компилировать в режиме C++ и переопределить оператор деления?

ส็็็็็็็็็็็็็็็็็็็็็็็็็༼ ຈل͜ຈ༽ส้้้้้้้้้้้้้้้้้้้้้้้

Ответить

- Исключение проявилось на ПК не из-за 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, )
        
        Только в андроиде, например, огораживание ещё более серьёзное. К чему бы то? - fk0(31.08.2012 13:31)
        
        Не надо путать сапоги и пряники. Unix тоже многозадачная система, и ANSI/ISO C тоже предполагает программы в многозадачной системе. И сигналы у каждой задачи свои. Ваши "хендлеры" и "исключения" ничем принципиально не отличаются от сигналов из fk0(221 знак., 30.08.2012 18:26)
        
        :))) -> - SciFi(30.08.2012 14:26, ссылка)
- Во-первых, я 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)

Средства и методы разработки