C++

Programmation Threads en C++

Recherche :

Mot : Pseudo : Filtrer
Page : 1 2 Page Suivante Page Précédente Bas de page
Auteur	Sujet : Programmation Threads en C++

Joel F

Real men use unique_ptr

Reprise du message précédent :
Code::Blocks marche très bien sous windows hein

Publicité

burn2

ça rox du poney

Je viens tout juste de l'installer pour voir. Mais déjà premier constat, je vois pas de création de projet console QT... Y a QT Gui mais pas console. Pas grave on va voir ce qu'on peu faire.

M'enfin c'est chiant quand même d'être bloqué comme ça.

EDIT: QT Creator avait l'air bien mais, le problème: c'est une version alpha, j'ai du rajouter moultes lib de dev c++ à la mano dans les dossier include et lib, et même comme ça ça ne compilait pas.
BRef pas du tout au point. En plus il me sortait une erreur du compilateur, sur un fichier init_proc ou un truc comme ça bref rien de comprehensible. Et y a rien dans les options de l'edi pour pouvoir faire des linkage etc, bref pas assez mûr pour le moment.

Message édité par burn2 le 10-11-2008 à 10:22:40

---------------
"C'est vrai qu'un type aussi pénible de jour on serait en droit d'espérer qu'il fasse un break de nuit mais bon …"

burn2

ça rox du poney

Bon c'est bon ça semble rouler avec Code::Blocks pour le moment tout va bien.

---------------
"C'est vrai qu'un type aussi pénible de jour on serait en droit d'espérer qu'il fasse un break de nuit mais bon …"

burn2

ça rox du poney

Bon juste un ptit chipotage, il pourrait me masquer les fonctions qui sont private dans la liste de quand on fait objet. à l'extérieur de la classe, mais bon là c'est du chipotage, sinon tout roule.
C'est quand même pas aussi bien intégré que sous linux avec un bon EDI ou QT est bien inclu et ou la doc est inclue dedans (là je me tapes une page web doc QT à côté avec contrôle F en continue m'enfin bon ça marche c'est déjà le principal).

---------------
"C'est vrai qu'un type aussi pénible de jour on serait en droit d'espérer qu'il fasse un break de nuit mais bon …"

burn2

ça rox du poney

Bon ben j'ai encore des problèmes, c'est à n'y rien comprendre.
Je lance le constructeur de ma classe, ou j'ai ça dedans:

Code :

cout<<"Constructeur avec param"<<endl;
//m_timer.start(3600);
QString program = QString::fromStdString(m_cmd);
//m_thread.startDetached (program);
m_thread.start("explorer.exe" );
Sleep(3000);
//Attente de l'éxécution de la commande
//m_thread.waitForFinished();
m_thread.kill();
//Attente de l'éxécution de la commande
//pthread_join(m_thread, NULL);

ça m'ouvre bien explorer.exe. Sauf que 3s plus tard, il n'est pas killé et qu'il continue sa vie, même si je stoppe mon application donc comme s'il était détaché. C'est pas du tout ce que je veux. Je peux même pas le killer.
et m_thread.waitForFinished(); n'est même pas bloquant. Je capte vraiment pas... Je continue à voir si je trouve des exemples.

Message édité par burn2 le 10-11-2008 à 15:28:37

---------------
"C'est vrai qu'un type aussi pénible de jour on serait en droit d'espérer qu'il fasse un break de nuit mais bon …"

burn2

ça rox du poney

Bon ben je m'en sors avec un process windows:

Code :

STARTUPINFO si;
PROCESS_INFORMATION pi;
ZeroMemory( &si, sizeof(si) );
si.cb = sizeof(si);
ZeroMemory( &pi, sizeof(pi) );
if( !CreateProcess( NULL, // No module name (use command line)
"C:\\Program Files\\Notepad++\\notepad++.exe", // Command line
NULL, // Process handle not inheritable
NULL, // Thread handle not inheritable
FALSE, // Set handle inheritance to FALSE
0, // No creation flags
NULL, // Use parent's environment block
NULL, // Use parent's starting directory
&si, // Pointer to STARTUPINFO structure
&pi ) // Pointer to PROCESS_INFORMATION structure
)
{
printf( "CreateProcess failed (%d)\n", GetLastError() );
return;
}
// Wait until child process exits.
WaitForSingleObject( pi.hProcess, INFINITE );
// Close process and thread handles.
CloseHandle( pi.hProcess );
CloseHandle( pi.hThread );

Me reste juste à pouvoir le killer ce process quand j'ai besoin...

J'adore windows, tu sais pas pourquoi mais quasiment rien ne marche, alros faut tester des moitiés de truc par si par là.

EDIT: et ça continue encore et encore, c'est que le début d'accord d'accord.....

Je prends le code d'un QTImer qui marche, sous linux que j'ai déjà utilisé, c'est dans la doc, je le fais sous windows et paf ça marche pas.

Code :

QTimer * m_timer;
m_timer = new QTimer();
connect(m_timer, SIGNAL(timeout()), this, SLOT(update()));
m_timer->start(10000);

et je me prends un :
T:\user\Developpement\Programmes_c++\execCMD\execCMD\application.cpp|21|error: invalid conversion from `QTimer*' to `SOCKET'|
T:\user\Developpement\Programmes_c++\execCMD\execCMD\application.cpp|21|error: cannot convert `const char*' to `const sockaddr*' for argument `2' to `int connect(SOCKET, const sockaddr*, int)'|

Visiblement c'est encore une mauvaise intégration sous windows de QT. Car visiblement connect existe déjà sous xp mais pour un socket... Du coup je sais pas du tout comment faire pour faire mon connect QT qui a le même nom...

Si je rajoute ma classe en QObject ça marche pas encore des erreurs incompréhensibles.
ça commence vraiment à me saturer windows...

EDIT2: Et si j'essaie de faire hériter ma classe de QThread comme il faut faire, ou de n'importe quoi je me prends un:

Citation :

obj\Release\application.o:application.cpp.text+0x7a)||undefined reference to `vtable for Application'|
obj\Release\application.o:application.cpp.text+0x3cc)||undefined reference to `vtable for Application'|
obj\Release\application.o:application.cpp.text+0x6fd)||undefined reference to `vtable for Application'|
obj\Release\application.o:application.cpp.text+0x971)||undefined reference to `vtable for Application'|
||=== Build finished: 4 errors, 0 warnings ===|

Je sature mais à un niveau là. Dire que j'aurais déjà tout fini sous linux ou avec quelque chose qui marche. Punaise mais je vais pas faire du C# bien lourd quand même pour ce genre de chose quoi. C'est pas possible.

Code :

cout<<"Constructeur avec param"<<endl;
STARTUPINFO si;
PROCESS_INFORMATION pi;
ZeroMemory( &si, sizeof(si) );
si.cb = sizeof(si);
ZeroMemory( &pi, sizeof(pi) );
if( !CreateProcess( NULL, // No module name (use command line)
"C:\\Program Files\\Notepad++\\notepad++.exe", // Command line
NULL, // Process handle not inheritable
NULL, // Thread handle not inheritable
FALSE, // Set handle inheritance to FALSE
0, // No creation flags
NULL, // Use parent's environment block
NULL, // Use parent's starting directory
&si, // Pointer to STARTUPINFO structure
&pi ) // Pointer to PROCESS_INFORMATION structure
)
{
printf( "CreateProcess failed (%d)\n", GetLastError() );
return;
}
// Wait until child process exits.
//WaitForSingleObject( pi.hProcess, INFINITE );
WaitForSingleObject( pi.hProcess, 10000 );
// Close process and thread handles.
TerminateProcess( pi.hProcess, 10 );
CloseHandle( pi.hProcess );
CloseHandle( pi.hThread );

Semble faire ce que je veux mais super le bricolage.

Message édité par burn2 le 17-09-2009 à 09:34:07

---------------
"C'est vrai qu'un type aussi pénible de jour on serait en droit d'espérer qu'il fasse un break de nuit mais bon …"

burn2

ça rox du poney

Voilà que les semaphore ne marchent pas sous windows non plus. Superrrrr.

Code :

sem_init(&sem, 0, NBTHREAD);
//On libère un semaphore (incrémentation)
//sem_post(&sem[i]);
for (int i=0; i<NBTHREAD;i++){
sem_wait(&sem);
cout<<i<<endl;
string fic="cmd";
pthread_create(&m_pgm[i].thread, NULL, thread, &fic);
}

Donc concrètement qu'est ce qui se passe, ça s'arrète bien au nombre de thread défini, sauf que paf error. Microsoft me pond une erreur, l'application c'est arrétée sans plus d'information...

Message édité par burn2 le 10-11-2008 à 21:39:16

---------------
"C'est vrai qu'un type aussi pénible de jour on serait en droit d'espérer qu'il fasse un break de nuit mais bon …"

Joel F

Real men use unique_ptr

pthread et sem truc c'ets du POSIX, donc pas dispo sous widnows en natif. Y a un portage (POSIX for windows) à récupérer

Message cité 1 fois

burn2

ça rox du poney

Joel F a écrit :

pthread et sem truc c'ets du POSIX, donc pas dispo sous widnows en natif. Y a un portage (POSIX for windows) à récupérer

Ben justement, j'ai récupéré la lib qui va bien avec les .h. Et ça compile. Sauf que visiblement ça ne marche pas...

Mais faudrait que je reteste car il se peut que l'erreur soit de ma faute là avec la fatigue, et en me relisant, j'ai peut-être merdé, et le message d'erreur serait du au fait que ça sort du programme sans fermer les thread avant, bref là à voir c'est peut-être ma faute sous la fatigue.
Cela dit windows me prend tellement la tête qu'en fin de journée je suis super fatigué. Sous linux ya bien longtemps que j'aurais fini en QT et puis basta. Là je suis obligé de bidouiller, trouver des solutions, et faire de la tambouille pour que ça marche. Pff c'est vraiment daubique et ça m'énerve mais à un point.
Je verrais ça Mercredi, mais bon, c'est bien moins foutu que ce que je voulais au final.

Message cité 1 fois
Message édité par burn2 le 10-11-2008 à 20:59:22

---------------
"C'est vrai qu'un type aussi pénible de jour on serait en droit d'espérer qu'il fasse un break de nuit mais bon …"

Tetedeiench

Head Of God

Faut bien voir que tu pars sur des portages de linux sous windows pour critiquer windows au final

Si tu codais directement, déjà, AMHA, ca irait mieux.

Personnellement, mes threads sous Delphi, pas d'API en dehors de celle filée par Borland, et je vais 100 fois plus vite que sous Linux avec QT

Y a aussi une énorme question d'habitude...

---------------
L'ingénieur chipset nortiaux : Une iFricandelle svp ! "Spa du pâté, hin!" ©®Janfynette | "La plus grosse collec vivante de bans abusifs sur pattes" | OCCT v12 OUT !

Publicité

burn2

ça rox du poney

Ben disons, que le truc, c'est que c'est des apis posix et standards hein. JE pars pas du principes que c'est du full linux. QT c'est multiplateforme etc, c'est que du multiplateforme ce que j'utilise, c'est pensé pour justement, pour pas perdre mes bases et si ça change de plateforme rester compatible.

Donc ça devrait normalement marcher Sauf qu'il n'y a pas d'EDI correctes (comparé à ce que je trouve sous nux) et que ce qui est sencé être compatible ne l'est pas, bienvenue dans le monde de crosoft ou un coup ça marche un coup pas, et là ben vu qu'on a pas accés aux entrailles de la bête on peut pas du tout bricoler sur l'EDI pour que tout marche out of the box, donc on est dépendant.

Y a une question d'habitude car oui, venant de linux, j'ai l'habitude de toujours pouvoir tout faire ce que je veux, chose qui n'est pas possible là. (en script je te racontes pas la galère!), car si ça marche pas, (chose qui est rare sur un truc prévu pour être full intégré) tu peux toujours éditer des fichiers de conf, chose impossible là...
Mais bon y a pas que ça hein, quand c'est sencé marcher ça doit marcher, là je trouve ça quand même anormal de devoir bricoler tenter des trucs qui marchent pas et devoir rester sur du full crosoft point.
Alors oui sous .net je pourais faire ça tranquilement, oui, sauf que je veux pas passer en .net sur un truc qui sera bien lourd pour une appli console quoi...

Et en fait, je fais pas vraiment de portage, je pars de 0. Mais quand je vois qu'un truc ne marche pas alors que ça devrait, pour être sûr que c'est pas moi, je reprends mon code utilisant cet objet fait sous linux et qui marchait à 100% qui devrait marcher (puisque l'api est la même donc l'utilisation et sa déclaration reste inchangée) et qui ne marche pas donc je suis sur que ça ne vient pas de mon code.
C'est juste une vérification mais il n'y a pas de portage linux vers windows.

Sinon niveau vitesse de développement c'est une question d'habitude et de langage, mais là je suis toujours sous le même langage et normalement avec des API Standard donc normalement multi plateformes

Message cité 1 fois
Message édité par burn2 le 10-11-2008 à 21:55:53

---------------
"C'est vrai qu'un type aussi pénible de jour on serait en droit d'espérer qu'il fasse un break de nuit mais bon …"

dap++

Script kiddie

Bonsoir,

burn2 a écrit :

J'utilise sans problème les pthreads sous Windows, il y a en tout et pour tout trois fichiers à installer. Si tu décrivais précisément ton erreur au lieu de troller, on pourrait peut-être t'aider...

burn2 a écrit :

Sinon niveau vitesse de développement c'est une question d'habitude et de langage, mais là je suis toujours sous le même langage et normalement avec des API Standard donc normalement multi plateformes

Et ben non. [:spamafote]

Joel F a écrit :

developpez.com: le fait d'etre ecrit par un tas de gens incompétents dans la plupart des catégories me suffit. Les tutoriels de gamins de 16 ans ou de gugus quis e disent que comme ils maitrisent PHP, ils maitrisent C++, ca me fait doucement rigoler. Le suel interet : la liste de pdf ecrit apr des vrais gens et des vrais profs.

[:poussahpensif]

Message cité 2 fois

---------------
dap.developpez.com

burn2

ça rox du poney

dap++ a écrit :

Bonsoir,

Bonsoir et merci de ta réponse

dap++ a écrit :

Le problème n'est pas avec phtread qui marche (sauf dans l'utilisation d'une classe, mais c'est une limite et j'ai trouvée comment outre passer ça). Mais avec le semaphore.
Et je n'ai pas le code sous les yeux, je ne suis plus au boulot là.
Merci de ton aide en tout cas.
Quand au message d'erreur, il n'y en a malheureusement pas, juste un rapport d'erreur à envoyer à microsoft.
Mais comme je l'ai dis sur cette partie là, je ne suis pas sûr de moi, donc, avant de confirmer que ça ne vient pas de ma programmation, je relirais tout ça au calme mercredi avant de bien en déduire qu'il y a une choucroute sur le sémaphore. Comme je l'ai dis pour cette partie là je suppose fortement que ma fin de code soit foirée par la fatigue et que donc sur mon test je merdoie et coupe le programme sans attendre la fin des thread, ce qui pourrait expliquer ces erreurs, donc j'attends de voir pour cette partie là. Sinon tout le reste marche oui.

Message édité par burn2 le 10-11-2008 à 23:15:50

---------------
"C'est vrai qu'un type aussi pénible de jour on serait en droit d'espérer qu'il fasse un break de nuit mais bon …"

dap++

Script kiddie

pthreads-win32 permet aussi d'utiliser les sémaphores en fait ? Je fais un test dès que je redémarre sous Windows.

Message cité 1 fois
Message édité par dap++ le 10-11-2008 à 23:23:58

---------------
dap.developpez.com

Joel F

Real men use unique_ptr

dap++ a écrit :

[:poussahpensif]

Quel est le message derrière ce smileys rigolo

burn2

ça rox du poney

dap++ a écrit :

pthreads-win32 permet aussi d'utiliser les sémaphores en fait ? Je fais un test dès que je redémarre sous Windows.

Ben si on utilise le même oui, y a 3 fichier dont un semaphore.h.
ça te permet d'utiliser les semaphores et les mutex.

---------------
"C'est vrai qu'un type aussi pénible de jour on serait en droit d'espérer qu'il fasse un break de nuit mais bon …"

burn2

ça rox du poney

Bon ben cette fois je confirme ça ne marche pas.

Code :

sem_init(&sem, 0, 5);
//On libère un semaphore (incrémentation)
//sem_post(&sem[i]);
for (int i=0; i<NBTHREAD;i++){
sem_wait(&sem);
cout<<i<<endl;
string fic="cmd";
pthread_create(&m_pgm[i].thread, NULL, thread, &fic);
}

Concrètement, nbthread est déclaré à 10, donc vu que j'ai que 5 semaphore, à i=5 ça devrait se stopper et attendre qu'un de mes thread l'incrémente. Hors dés que j'atteinds ce seuil, donc quand i=5 et que le semaphore atteinds le niveau 0, je me prends une erreur du programme sans aucune explication, juste avant d'affichier i=5 donc bien exactement sur cette ligne là...
Je l'ai pourtant intialisé et il n'y a pas de deadlock, et même un deadlock ne devrait pas causer la fermeture brusque du programme sans explication, une fois la fin du programme atteinte.
Total je vais devoir faire mon propre semaphore à la mano...
j'ai juste ça comme infos:

Citation :

Signature du problème :
Nom d’événement de problème: APPCRASH
Nom de l’application: execCMD.exe
Version de l’application: 0.0.0.0
Horodatage de l'application: 491a8996
Nom du module par défaut: msvcrt.dll
Version du module par défaut: 7.0.6001.18000
Horodateur du module par défaut: 4791a727
Code de l’exception: c0000005
Décalage de l’exception: 00009f26

Je vais chercher sur internet...

EDIT: et concrètement je ne sais même pas si les mutex marchent eux aussi vu qu'il faudrait que je fasse exprès de faire une concurrence d'accés pour voir si ça attends bien...

EDIT2: Vous savez quoi????? Et bien ça vient de vista! J'essaye mon exécutable sous XP et tout marche bien! :fou: :fou: :fou: :fou: :fou: :fou: :fou: :fou:

Bon vu comment je galère, comment ça devient problématique et vraiment concrètement, c'est plus du boulot. Je bascule en C#.net y a pas le choix.
http://msdn.microsoft.com/en-us/li [...] phore.aspx pour les semaphore et thread. Mais c'est abusé quand même ça, je trouve ça totalement anormal.

Message édité par burn2 le 12-11-2008 à 09:27:13

---------------
"C'est vrai qu'un type aussi pénible de jour on serait en droit d'espérer qu'il fasse un break de nuit mais bon …"

xilebo

noone

As tu recompilé les pthreads pour vista ? parceque si tu as récupéré les binaires (dll) sur internet, ils ont surement été compilé pour windows XP. Récupères les sources pthread-win32 et compile les sous vista.

burn2

ça rox du poney

Heu ben non je n'ai pas recompilé, effectivement ça peut être ça, mais bon, personnellement, je ne veux pas de chose qui doivent être recompilé pour passer. Quand on va rechanger d'os ça va encore re être le bordel. Les machines sont sous xp pour le moment mais notre parc va changer trés rapidement, donc il me faut du portable soit en crosoft attitude .net histoire de pas me prendre la tête et si on a du linux je développerais ça mais ça sera rapide. Mais si je commence déjà à devoir recompiler pour xp puis pour vista etc... C'est sans fin.

Mais bon ça serait bien qu'ils fournissent des infos pour moi quand j'ai une lib, je la prends je l'utilises point. Je vais voir si c'est effectivement ça. Ce qui serait fortement possible.

EDIT:
Sauf que si je vais dans le dossier qui va bien et que j'exécute:
builddmc.bat c'est le drame, ce n'est visiblement pas prévu pour être compilé sous vista...

Message édité par burn2 le 12-11-2008 à 10:51:23

---------------
"C'est vrai qu'un type aussi pénible de jour on serait en droit d'espérer qu'il fasse un break de nuit mais bon …"

burn2

ça rox du poney

Et ça continue les déboires :lol:
Je crée un process sous windows et paf, il veut pas. j'ai pas l'autorisation pour le faire.
Je me tapes une security exception alors que je suis admin! Y a pas j'adore vista :love: :love:

EDIT:
J'ai trouvé comment faire!
Propriété du projet etc. Mais franchement :lol: Quel prise de tête, et aucune information dans la doc...

EDIT2: Alors pareil, si j'exécute mon programme dans mon dossier sur le réseau ça se croute avec une erreur incompréhensible, mais si je copie l'exécutable et l'exécute depuis mon bureau ben là ça marche. :love: :love:
Alors que j'ai des try catch de partout. Ah que c'est bien le développement sous windows vista.

Message édité par burn2 le 12-11-2008 à 14:55:07

---------------
"C'est vrai qu'un type aussi pénible de jour on serait en droit d'espérer qu'il fasse un break de nuit mais bon …"

burn2

ça rox du poney

Bon cette fois en C# j'arrive à mieux, tout marche pour le moment et exactement comme je veux. C'est quand même abusé de devoir utiliser du .net point sinon ça merde.

---------------
"C'est vrai qu'un type aussi pénible de jour on serait en droit d'espérer qu'il fasse un break de nuit mais bon …"

burn2

ça rox du poney

Bon ben voilà, j'ai fini mon programme. Et ça marche nickel. Mais obligé de le faire en C#... Merci microsoft.

---------------
"C'est vrai qu'un type aussi pénible de jour on serait en droit d'espérer qu'il fasse un break de nuit mais bon …"

frenchtoucco

quel est l'avantage de boost::thread par rapport à pthread

---------------
je connais tout, je ne sais rien, seule certitude, à vouloir trop on finit par tout perdre.

Joel F

Real men use unique_ptr

en gros c'est multi-plateforme déjà et ca utilise la RAII pr eviter les drames classiqeus des mutex foireux. L'interface à base de foncteur est sans ocmmuen mesure avec le void* de chez mamie pthread.

Publicité

Page : 1 2

Page Suivante

Page Précédente

Haut de page

FORUM HardWare.fr

Programmation

C++

Programmation Threads en C++

Sujets relatifs
utiliser une dll compilée en C# dans un projet VisualC++	Exercices programmation C++
VBA - C++ - DLL	Récupération de temps de réponse (PING) en C
[DRUPAL] C'est içi?	probleme de programmation en C
programmation ds Alice avec le language Xml ou SML niveau debutant	[C#] simuler un click souris [résolu]
Plus de sujets relatifs à : Programmation Threads en C++

Page générée en 0.136 secondes