class handl {
public:
void evthandler(int x) {};
};
int main()
{
handl * hndl = new handl();
signal(SIGTERM,&handl::evthandler);
...
return 0;
}
приведение void (my_class::*)(int) к void (*)(int)
Собсвенно САБЖ.
Вот пример кода:
Матюкается(и правильно делает :) ):
Cannot convert 'void (handl::*)(int)' to 'void (*)(int)' to assignment
Как побороть сию зверюгу?
Вот пример кода:
Код:
Матюкается(и правильно делает :) ):
Cannot convert 'void (handl::*)(int)' to 'void (*)(int)' to assignment
Как побороть сию зверюгу?
ну ты извращенец однако.. классовые функции разрешено только так и передавать через (handl::*).. но ты можешь сделать эту функцию статичной
тогда можно вызывать эту функцию через класс, а не через его экземпляр.. а так неизвестно, привяжешь ты полученный указатель к экземпляру и к какому экземпляру - неизвестно.. решение проблемы - рефакторинг кода. передавай временные экземпляры через auto_ptr либо вообще пользуйся не сигналами, а исключениями.. :cool:
Код:
class handl {
public:
static void evthandler(int x) {};
};
public:
static void evthandler(int x) {};
};
тогда можно вызывать эту функцию через класс, а не через его экземпляр.. а так неизвестно, привяжешь ты полученный указатель к экземпляру и к какому экземпляру - неизвестно.. решение проблемы - рефакторинг кода. передавай временные экземпляры через auto_ptr либо вообще пользуйся не сигналами, а исключениями.. :cool:
Дело в том, что в процессе в один момент времени может быть только один обработчик сигнала.
Поэтому, если используются "ненадежные" сигналы на основе signal (не то что бы в них содержаться ошибки, просто у них куча недостатков при использовании в многопоточных приложениях), то обработчик должен быть статичен и размещаться в глоблальной памяти (иметь тип static).
Концепция "надежныйх" сигналов sigaction требует уже статичную структуру sigaction и глобального обработчика.
Да, и судя по попытке разместить обработчик сигнала в классе, учти что в используемых тобой модели сигналов signal, обработчик сбрасывается на стандартный, после первого вызова =).
Если используешь многопоточное приложение и тебе надо освободить ресурсы, захваченные каждым из потоков по сигналу (а они находятся в общей для потоков памяти), то лучше ИМХО на обработчик повесить установку глобального флажка, а потом по этому флажку в каждом потоке уже и "мусор" собирать.
Поэтому, если используются "ненадежные" сигналы на основе signal (не то что бы в них содержаться ошибки, просто у них куча недостатков при использовании в многопоточных приложениях), то обработчик должен быть статичен и размещаться в глоблальной памяти (иметь тип static).
Концепция "надежныйх" сигналов sigaction требует уже статичную структуру sigaction и глобального обработчика.
Да, и судя по попытке разместить обработчик сигнала в классе, учти что в используемых тобой модели сигналов signal, обработчик сбрасывается на стандартный, после первого вызова =).
Если используешь многопоточное приложение и тебе надо освободить ресурсы, захваченные каждым из потоков по сигналу (а они находятся в общей для потоков памяти), то лучше ИМХО на обработчик повесить установку глобального флажка, а потом по этому флажку в каждом потоке уже и "мусор" собирать.
Цитата:
вообще пользуйся не сигналами, а исключениями..
вообще сигналы, кроме всего прочего являюся еще и IPC, тогда причем здесь исключения?...
я не очень дружу с сигналами и подумал, что идёт речь об обработке ошибок через сигналы. в любом случае передавать указатели на не статичные методы в С-like функциях это бессмыслица.. что бы это под собой не подразумевало