bonjour,
pour les threads je ne sert d'une strategie a la "java"
une classe abstraite pure (Interface)
class Runnable{
public:
virtual void run() = 0;
}
class RXEngine : public Runnable {
void RXEngine::dansUneFonctionInit() {
param.init();
RXThread thread(this);
thread.start();
}
void RXEngine::run() {
//ici je peu utiliser la variable d'instance param
}
il y a t'il une facon plus elegante des passer la variable "param"
bonjour,
pour les threads je ne sert d'une strategie a la "java"
une classe abstraite pure (Interface)
class Runnable{
public:
virtual void run() = 0;
}
class RXEngine : public Runnable {
void RXEngine::dansUneFonctionInit() {
param.init();
RXThread thread(this);
thread.start();
}
void RXEngine::run() {
//ici je peu utiliser la variable d'instance param
}
il y a t'il une facon plus elegante des passer la variable "param"
bonjour,
pour les threads je ne sert d'une strategie a la "java"
une classe abstraite pure (Interface)
class Runnable{
public:
virtual void run() = 0;
}
class RXEngine : public Runnable {
void RXEngine::dansUneFonctionInit() {
param.init();
RXThread thread(this);
thread.start();
}
void RXEngine::run() {
//ici je peu utiliser la variable d'instance param
}
il y a t'il une facon plus elegante des passer la variable "param"
Après c'est le début des problèmes :)
Après c'est le début des problèmes :)
Après c'est le début des problèmes :)
"Michael DOUBEZ" a écrit dans le message de news:
48c8f556$0$7602$Après c'est le début des problèmes :)
tu peux developper un peu :)
"Michael DOUBEZ" <michael.doubez@free.fr> a écrit dans le message de news:
48c8f556$0$7602$426a74cc@news.free.fr...
Après c'est le début des problèmes :)
tu peux developper un peu :)
"Michael DOUBEZ" a écrit dans le message de news:
48c8f556$0$7602$Après c'est le début des problèmes :)
tu peux developper un peu :)
pour les threads je ne sert d'une strategie a la "java"
une classe abstraite pure (Interface)
class Runnable{
public:
virtual void run() = 0;
}
un classe thread tres simple (un simple wrapper des threads POSIX)
class POSIXThread {
pthread_t _threadID;
public :
POSIXThread(Runnable *ptr);
virtual ~POSIXThread() {};
void start();
protected:
static void* threadfunction(void * pt);
Runnable* _threadObj;
};
class RXEngine : public Runnable {
.../...
//variable d'instance
RXParamThread param;
//metode d'instance
void dansUneFonctionInit();
virtual void run();
};
void RXEngine::dansUneFonctionInit() {
param.init();
RXThread thread(this);
thread.start();
}
void RXEngine::run() {
//ici je peu utiliser la variable d'instance param
}
il y a t'il une facon plus elegante des passer la variable
"param"
pour les threads je ne sert d'une strategie a la "java"
une classe abstraite pure (Interface)
class Runnable{
public:
virtual void run() = 0;
}
un classe thread tres simple (un simple wrapper des threads POSIX)
class POSIXThread {
pthread_t _threadID;
public :
POSIXThread(Runnable *ptr);
virtual ~POSIXThread() {};
void start();
protected:
static void* threadfunction(void * pt);
Runnable* _threadObj;
};
class RXEngine : public Runnable {
.../...
//variable d'instance
RXParamThread param;
//metode d'instance
void dansUneFonctionInit();
virtual void run();
};
void RXEngine::dansUneFonctionInit() {
param.init();
RXThread thread(this);
thread.start();
}
void RXEngine::run() {
//ici je peu utiliser la variable d'instance param
}
il y a t'il une facon plus elegante des passer la variable
"param"
pour les threads je ne sert d'une strategie a la "java"
une classe abstraite pure (Interface)
class Runnable{
public:
virtual void run() = 0;
}
un classe thread tres simple (un simple wrapper des threads POSIX)
class POSIXThread {
pthread_t _threadID;
public :
POSIXThread(Runnable *ptr);
virtual ~POSIXThread() {};
void start();
protected:
static void* threadfunction(void * pt);
Runnable* _threadObj;
};
class RXEngine : public Runnable {
.../...
//variable d'instance
RXParamThread param;
//metode d'instance
void dansUneFonctionInit();
virtual void run();
};
void RXEngine::dansUneFonctionInit() {
param.init();
RXThread thread(this);
thread.start();
}
void RXEngine::run() {
//ici je peu utiliser la variable d'instance param
}
il y a t'il une facon plus elegante des passer la variable
"param"
static void* threadfunction(void * pt);
Si ça fait ce que je pense (c-à-d être passer à pthread_create),
le code ne doit pas compiler. (Il y a un bug à cet égard dans
g++, mais d'autres compilateurs C++ s'en plaignent, comme il
faut.)
Plus élégante que quoi ? Tu crées une classe dérivée de
Runnable, avec les membres qu'il te faut. Tu le constructes, ce
qui initialise les membres (éventuellement avec les paramètres
passés au constructeur), et tu passes l'objet à un POSIXThread,
qui démarre le thread. Le thread a bien accès à tous les membres
de la classe, y compris ceux initialisés à partir des paramètres
du constructeur. Quelque chose du genre :
La seule difficulté réele, c'est la gestion de la durée de vie
des objets.
static void* threadfunction(void * pt);
Si ça fait ce que je pense (c-à-d être passer à pthread_create),
le code ne doit pas compiler. (Il y a un bug à cet égard dans
g++, mais d'autres compilateurs C++ s'en plaignent, comme il
faut.)
Plus élégante que quoi ? Tu crées une classe dérivée de
Runnable, avec les membres qu'il te faut. Tu le constructes, ce
qui initialise les membres (éventuellement avec les paramètres
passés au constructeur), et tu passes l'objet à un POSIXThread,
qui démarre le thread. Le thread a bien accès à tous les membres
de la classe, y compris ceux initialisés à partir des paramètres
du constructeur. Quelque chose du genre :
La seule difficulté réele, c'est la gestion de la durée de vie
des objets.
static void* threadfunction(void * pt);
Si ça fait ce que je pense (c-à-d être passer à pthread_create),
le code ne doit pas compiler. (Il y a un bug à cet égard dans
g++, mais d'autres compilateurs C++ s'en plaignent, comme il
faut.)
Plus élégante que quoi ? Tu crées une classe dérivée de
Runnable, avec les membres qu'il te faut. Tu le constructes, ce
qui initialise les membres (éventuellement avec les paramètres
passés au constructeur), et tu passes l'objet à un POSIXThread,
qui démarre le thread. Le thread a bien accès à tous les membres
de la classe, y compris ceux initialisés à partir des paramètres
du constructeur. Quelque chose du genre :
La seule difficulté réele, c'est la gestion de la durée de vie
des objets.
"James Kanze" a écrit dans le message de news:
>> static void* threadfunction(void * pt);
>Si ça fait ce que je pense (c-à-d être passer à pthread_create),
>le code ne doit pas compiler. (Il y a un bug à cet égard dans
>g++, mais d'autres compilateurs C++ s'en plaignent, comme il
>faut.)
void* POSIXThread::threadFunction(void* pt) {
Runnable* runnable = static_cast< Runnable*>(pt);
runnable->run();
return NULL;
}
oui j'utilise g++ (seul gratuit sur macos),pas un warning.
>Plus élégante que quoi ? Tu crées une classe dérivée de
>Runnable, avec les membres qu'il te faut. Tu le constructes, ce
>qui initialise les membres (éventuellement avec les paramètres
>passés au constructeur), et tu passes l'objet à un POSIXThread,
>qui démarre le thread. Le thread a bien accès à tous les membres
>de la classe, y compris ceux initialisés à partir des paramètres
>du constructeur. Quelque chose du genre :
> RXEngine engin( ... ) ;
> POSIXThread thread( &engin ) ;
> thread.start()
c'est exactement ma solution ? non?
>La seule difficulté réele, c'est la gestion de la durée de
>vie des objets.
oui, mes threads ont la durée de vie du programme.
"James Kanze" <james.ka...@gmail.com> a écrit dans le message de news:
5646e2e0-88c9-4f5d-bf9b-82fb36e8c...@p25g2000hsf.googlegroups.com...
>> static void* threadfunction(void * pt);
>Si ça fait ce que je pense (c-à-d être passer à pthread_create),
>le code ne doit pas compiler. (Il y a un bug à cet égard dans
>g++, mais d'autres compilateurs C++ s'en plaignent, comme il
>faut.)
void* POSIXThread::threadFunction(void* pt) {
Runnable* runnable = static_cast< Runnable*>(pt);
runnable->run();
return NULL;
}
oui j'utilise g++ (seul gratuit sur macos),pas un warning.
>Plus élégante que quoi ? Tu crées une classe dérivée de
>Runnable, avec les membres qu'il te faut. Tu le constructes, ce
>qui initialise les membres (éventuellement avec les paramètres
>passés au constructeur), et tu passes l'objet à un POSIXThread,
>qui démarre le thread. Le thread a bien accès à tous les membres
>de la classe, y compris ceux initialisés à partir des paramètres
>du constructeur. Quelque chose du genre :
> RXEngine engin( ... ) ;
> POSIXThread thread( &engin ) ;
> thread.start()
c'est exactement ma solution ? non?
>La seule difficulté réele, c'est la gestion de la durée de
>vie des objets.
oui, mes threads ont la durée de vie du programme.
"James Kanze" a écrit dans le message de news:
>> static void* threadfunction(void * pt);
>Si ça fait ce que je pense (c-à-d être passer à pthread_create),
>le code ne doit pas compiler. (Il y a un bug à cet égard dans
>g++, mais d'autres compilateurs C++ s'en plaignent, comme il
>faut.)
void* POSIXThread::threadFunction(void* pt) {
Runnable* runnable = static_cast< Runnable*>(pt);
runnable->run();
return NULL;
}
oui j'utilise g++ (seul gratuit sur macos),pas un warning.
>Plus élégante que quoi ? Tu crées une classe dérivée de
>Runnable, avec les membres qu'il te faut. Tu le constructes, ce
>qui initialise les membres (éventuellement avec les paramètres
>passés au constructeur), et tu passes l'objet à un POSIXThread,
>qui démarre le thread. Le thread a bien accès à tous les membres
>de la classe, y compris ceux initialisés à partir des paramètres
>du constructeur. Quelque chose du genre :
> RXEngine engin( ... ) ;
> POSIXThread thread( &engin ) ;
> thread.start()
c'est exactement ma solution ? non?
>La seule difficulté réele, c'est la gestion de la durée de
>vie des objets.
oui, mes threads ont la durée de vie du programme.
Après c'est le début des problèmes :)
tu peux developper un peu :)
Principalement, la gestion de la synchronisation entre l'arrêt du thread
et la destruction de l'objet, et le cas d'un thread qui meure
brutalement et donc ne dépile pas sa stack (au revoir RAII).
Il y a aussi certaines précautions à prendre comme mettre un catch à la
base de ta fonction dans le thread (et aussi comment remonter l'erreur à
l'objet appelant).
Après c'est le début des problèmes :)
tu peux developper un peu :)
Principalement, la gestion de la synchronisation entre l'arrêt du thread
et la destruction de l'objet, et le cas d'un thread qui meure
brutalement et donc ne dépile pas sa stack (au revoir RAII).
Il y a aussi certaines précautions à prendre comme mettre un catch à la
base de ta fonction dans le thread (et aussi comment remonter l'erreur à
l'objet appelant).
Après c'est le début des problèmes :)
tu peux developper un peu :)
Principalement, la gestion de la synchronisation entre l'arrêt du thread
et la destruction de l'objet, et le cas d'un thread qui meure
brutalement et donc ne dépile pas sa stack (au revoir RAII).
Il y a aussi certaines précautions à prendre comme mettre un catch à la
base de ta fonction dans le thread (et aussi comment remonter l'erreur à
l'objet appelant).
oui, mes threads ont la durée de vie du programme.
Dans quel cas, pas de problème:-). Tu les alloues dynamiquement,
et tu n'en fais jamais de delete, et ça marche.
oui, mes threads ont la durée de vie du programme.
Dans quel cas, pas de problème:-). Tu les alloues dynamiquement,
et tu n'en fais jamais de delete, et ça marche.
oui, mes threads ont la durée de vie du programme.
Dans quel cas, pas de problème:-). Tu les alloues dynamiquement,
et tu n'en fais jamais de delete, et ça marche.
Michael DOUBEZ wrote on 11/09/2008 13:58:
>>> Après c'est le début des problèmes :)
>> tu peux developper un peu :)
> Principalement, la gestion de la synchronisation entre
> l'arrêt du thread et la destruction de l'objet, et le cas
> d'un thread qui meure brutalement et donc ne dépile pas sa
> stack (au revoir RAII).
l' "object" ? celui qui représente ce thread justement ?
après le passage par une fonction système qui invoque une
fonction static de cet object, on récupère cette instance pour
appeler son 'run' l'arrêt du thread doit correspondre à la vie
de fin de cet objet (et vice versa d'ailleurs).
la mort brutale doit être gérée, comme tu le dis, via un catch
à plus haut niveau (run itself sûrement).
> Il y a aussi certaines précautions à prendre comme mettre un
> catch à la base de ta fonction dans le thread (et aussi
> comment remonter l'erreur à l'objet appelant).
présumer de l'existence de cet appelant est risqué / douteux.
je broadcasterais plutôt un message.
Michael DOUBEZ wrote on 11/09/2008 13:58:
>>> Après c'est le début des problèmes :)
>> tu peux developper un peu :)
> Principalement, la gestion de la synchronisation entre
> l'arrêt du thread et la destruction de l'objet, et le cas
> d'un thread qui meure brutalement et donc ne dépile pas sa
> stack (au revoir RAII).
l' "object" ? celui qui représente ce thread justement ?
après le passage par une fonction système qui invoque une
fonction static de cet object, on récupère cette instance pour
appeler son 'run' l'arrêt du thread doit correspondre à la vie
de fin de cet objet (et vice versa d'ailleurs).
la mort brutale doit être gérée, comme tu le dis, via un catch
à plus haut niveau (run itself sûrement).
> Il y a aussi certaines précautions à prendre comme mettre un
> catch à la base de ta fonction dans le thread (et aussi
> comment remonter l'erreur à l'objet appelant).
présumer de l'existence de cet appelant est risqué / douteux.
je broadcasterais plutôt un message.
Michael DOUBEZ wrote on 11/09/2008 13:58:
>>> Après c'est le début des problèmes :)
>> tu peux developper un peu :)
> Principalement, la gestion de la synchronisation entre
> l'arrêt du thread et la destruction de l'objet, et le cas
> d'un thread qui meure brutalement et donc ne dépile pas sa
> stack (au revoir RAII).
l' "object" ? celui qui représente ce thread justement ?
après le passage par une fonction système qui invoque une
fonction static de cet object, on récupère cette instance pour
appeler son 'run' l'arrêt du thread doit correspondre à la vie
de fin de cet objet (et vice versa d'ailleurs).
la mort brutale doit être gérée, comme tu le dis, via un catch
à plus haut niveau (run itself sûrement).
> Il y a aussi certaines précautions à prendre comme mettre un
> catch à la base de ta fonction dans le thread (et aussi
> comment remonter l'erreur à l'objet appelant).
présumer de l'existence de cet appelant est risqué / douteux.
je broadcasterais plutôt un message.
James Kanze wrote on 11/09/2008 16:50:
>> oui, mes threads ont la durée de vie du programme.
> Dans quel cas, pas de problème:-). Tu les alloues dynamiquement,
> et tu n'en fais jamais de delete, et ça marche.
pourquoi pas:
void* POSIXThread::threadFunction(void* ref){
Runnable* runnable = static_cast<Runnable*>(ref);
if (runnable){
try {
runnable->run();
}
catch (...){
}
delete runnable
}
return NULL;
}
??
purger proprement des threads à durée de vie courte ne me
parait pas tordu ?!
James Kanze wrote on 11/09/2008 16:50:
>> oui, mes threads ont la durée de vie du programme.
> Dans quel cas, pas de problème:-). Tu les alloues dynamiquement,
> et tu n'en fais jamais de delete, et ça marche.
pourquoi pas:
void* POSIXThread::threadFunction(void* ref){
Runnable* runnable = static_cast<Runnable*>(ref);
if (runnable){
try {
runnable->run();
}
catch (...){
}
delete runnable
}
return NULL;
}
??
purger proprement des threads à durée de vie courte ne me
parait pas tordu ?!
James Kanze wrote on 11/09/2008 16:50:
>> oui, mes threads ont la durée de vie du programme.
> Dans quel cas, pas de problème:-). Tu les alloues dynamiquement,
> et tu n'en fais jamais de delete, et ça marche.
pourquoi pas:
void* POSIXThread::threadFunction(void* ref){
Runnable* runnable = static_cast<Runnable*>(ref);
if (runnable){
try {
runnable->run();
}
catch (...){
}
delete runnable
}
return NULL;
}
??
purger proprement des threads à durée de vie courte ne me
parait pas tordu ?!