A tous et toutes, je m'en viens querrir votre aide.
 
Alors je vous explique le contexte, je suis en train de développer une application threadée qui me permettra d'exécuter une application ou un scrip à partir d'un fichier texte déposé dans ce répertoire en ftp (de façon à pouvoir lancer des commandes windows automatiquement quand l'as400 le demande en déposant un fichier dans le répertoire que j'annalyse), et il me faut faire plusieurs choses.
Le pc sera sous windows Xp ou vista en fonction mais ça doit marcher sur les deux.
J'utilise la lib pthreads et jusque là tout va bien, la création d'un thread marche, j'ai du mettre des libs dans le dossier pour que ça passe sous xp, mais normal quoi.
 
Non le problème que j'ai c'est au niveau programmation:
Donc, contrètement il va y avoir X threads qui tourneront en même temps. Chaque threads sera une application lancé ou un script.
Le problème que j'ai pour le moment, c'est que pour exécuter le programme externe je fais  

par exemple, mais le problème, c'est que cet appel crée un thread qui va vivre sa vie sans aucun contrôle, or, j'ai besoin que ça reste dans le thread en sécence, car je dois créer un accusé de réception à partir du moment ou la commande (qui dans ce cas là est dans la commande system) et terminée un exemple en algo rapide est plus parlant:

 
On comprend bien le problème, si je déroule, je vais créer le fichier d'accusé avant d'avoir fini d'éxécuter la commande system, car dans le thread, ce n'est pas séquenciel.
Ma question est donc comment dans le thread attendre la fin de l'exécution de system??? Ou alors y a t'il une autre manière de lancer une commande que ça soit cmd ou un script créé à la main qui soit fait, mais séquenciellement pour que le fichier d'accusé ne soit créé que lorsque la commande est terminée. Car derrière l'as400 va attendre que ce fichier soit créé pour aller chercher le résultat de cette commande. Une idée de comment faire ça???  
 
 
 
 
Autre question, mon programme est prévu pour tourner en continue, et il est évident, que je ne peux savoir ce qui se passe derrière au niveau du programme exécuté.
Y a t'il moyen de savoir depuis quand un thread a été créé avec phtread???? Ceci afin de créer un "garbage_collector()" qui détruira les threads qui sont bloqué depuis par exemple 3h ou autre, à définir, car le nombre de threads ne sera pas illimité de mon côté, pour ne pas saborder toute la machine, ça sera limité à 4 voir 6 par là à voir, et donc on comprends bien que si une commande que j'exécute se plante, je bloque un thread définitivement jusqu'a la coupure du programme, et donc ça demande manipulation, ce qui n'est pas prévu, donc est-il possible de tuer un phtread au bou d'un moment?
(ua pire si y a pas de fonction dans pthread qui fasse ça, je peux créer une classe ou je met une variable en int qui correspond au nombre d'heure que tourne ce thread ça c'est pas compliqué, mais bon si ça existe déjà autant pas le reprogrammer et surtout il me faut pouvoir tuer le processus quand je le juge nécéssaire).

boost::thread et boost::asio répondront à la plupart de tes problèmes.

Merci, effectivement y a l'air d'avoir tout ce qu'il faut!
http://matthieu-brucher.developpez [...] st/thread/
 
Faut que je voye pour l'histoire de l'équivalent de system("..." ) je vois comment faire, mais bon ça m'aurait arrangé de pas changer de bibliothèque si possible, mais bon là au moins j'ai une solution, donc merci. Si jamais quelqu'un passe par là et sait comment faire avec phtread au cas ou.
 
 
Et y a encore pas mal d'infos ici:
http://franckh.developpez.com/tuto [...] /pthreads/

developpez.com   la vrai doc de bosot est quand même plus avantageuse.
 
Sinon pour system, boost::process mais je sais pas si elle est inclus ou encore en cours de valdiation. Sinon, CreateProcess est ton ami
 

Non mais sur développez.com ils mettent qu'on peut mettre un exécutable en thread donc suffit d'attendre sa fin.
Mais bon je préfèrerais rester sur pthread que je connais plus, enfin vraiment de préférence, et surtout car ça passe sous nux sans aucune modification, du coup, mon corde sera portable sans rajouter de lib sous linux. Ce qui me va pour le futur.
J'ai d'autres infos ici sur pthread: https://computing.llnl.gov/tutorials/pthreads/
http://cs.pub.ro/~apc/2003/resourc [...] cument.htm
Je connaissais pas boost par contre. ET si vraiment je trouve pas comment faire j'y basculerais, mais pthread me semble pls logique vu la doc qui existe et sa portabilitée.
 
En fait pour l'instant sur phtread, je ne vois qu'un problème c'est mon appel system, pour le reste tout se goupille dans ma tête et je sais comment le faire. Reste juste à savoir comment remplacer mon system("..." ) par autre chose qui permette d'attendre que l'action soit terminée pour que ça continue. Et cela dit d'après ce que je vois le problème est identique sous boost. ME manque vraiment que ça.  
 
Au fait pourquoi t'aimes pas développez.com???

un thread et un thread , c'est pas un processus, c'ets fondamentalement différent.
 
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.

Oué donc concrètement, faudrait plus que je me penche vers les process pour exécuter la commande. Mais bon là ça va être dépendant de la plateforme.
Y a pas moyen de faire l'équivalent d'un exec de linux? Enfin si j'ai bien compris comment ça marche l'exec sous linux, ça recouvre bien le code durant le temps de l'exécution de ce qui est aprés exec et dés que c'est fini ça reprends la suite non?? ce qui est exactement ce que je cherche non?

En tout cas je te remercie de ton aide déjà pour les réponses.
 
EDIT: Exec existe visiblement sous windows aussi, à priori, est ce que vous pensez que ça convient pour ce que je veux??

sous windows c'ets CreateProcess

ça me semble uun peu bourin de recréer un process si exec suffit non? (enfin la la question est : "est ce que j'ai bien compris comment marche exec?" )
Parce que si exec, c'est bien, j'exécute le programme en séquence et je rends la main à la fin de mon exécution et j'exécute ce qu'il y a après alors c'est exactement ce que je veux...

Mais que crois tu que fasse exec ???
http://msdn.microsoft.com/en-us/library/ms682425.aspx

Bah oui donc du coup, c'est bon c'est exactement ce qu'il faut non?
mais la seule question que je me pose c'est est ce qu'a la fin de l'éxécution du exec on continue avec ce qui y a derrière dans mon code qui a fait l'exec ou ça remplace le thread point et on ne revient plus dessus?
EDIT:

Donc bon ça doit bien revenir sur la boucle
ça me semble donc parfait, et je vois bien comment goupiller tout mon programme ainsi que mon garbage collector

Bon j'ai quand même un ptit pb avec pthread.  
Si je déclare un pthread_t test;
et que je fais test.
dans la liste j'ai Stop() etc. je fais
test.stop() et il me dit que cette fonction n'existe pas dans la structure pthread_t
 
Problématique pour pouvoir le killer, y a quelque chose qui crouttoie...
 
EDIT: ça doit être l'EDI qui me sort des fonctions nawac. Bon par contre , j'arrive pas à déclarer une fonction thread en interne à la clase.
Dés que je le mets en méthode membre:
 

vu que j'ai besoin que cette méthode de thread soit interne à ma classe mais il veut pas.

pthread_t c 'est juste une structure, on est aps en JAVA.
pthread_cancel pour tuer un thread. Sauf que je viens de te dire que t'as besoin de processus.

Revoie tes bases de systeme.

Et si c'ets pr reinventer la roue : boost::thread et boost::asio

J'ai pas besoin de processus pour ce que je veux faire, je suis pas au niveau de lancer l'application, j'ai d'autres traitements avant. Dans mon thread je ferais un exec, ça sera parfait et j'aurais quand même moyen de le détruire, sinon oui j'ai vu pour le tuer, mais c'est mon edi qui fumait et me sortait des méthodes membres du coup....
 
Mais bon là la question qui cloche, c'est comment déclarer un thread en interne.
Si je met une méthode non membre de la classe ça marche, sauf que pour accéder au variables de cette classe ben poupougne quoi. Et là je capte pas ce qui bloque.
 
Enfin je vais regarder boost au cas ou mais l'intéraction avec les semaphore et mutex ne pose pas de problème?
Et cela dit je ne vois pas la différence avec boost? Concrètement ça va m'apporter quoi de plus boost?
Un thread est un thread, j'ai pas vraiment envie de me prendre la tête à comprendre une autre api si elle ne m'apporte rien de plus quoi.  
Dans mon cas j'ai juste besoin de créer un thread, dans un thread je ferais un exec. Et dans l'autre c'est juste un timer....
Mais le problème c'est que je n'arrive pas à déclarer ces thread (la fonction associée au thread) en interne à la classe.

c'ets bien ce que je dis t'as pas compris les bases
Dis moi ce que tu crois que fait exec.
 
Pour tes histories de thread tout ça, boost::thread et picétout

Pour moi exec, fait l'équivalent de system("..." ) mais en étant en séquence, ça remplace le code du thread durant l'éxécution de la commande prévue, un process si tu veux, mais ça c'est pas vraiment le principal, ce que je veux c'est que ça s'enchaine en séquence dans mon thread, chose qui ne se passe pas avec la commande system, et que si cette commande est longue, que la suite de mon thread ne s'enchaine pas et si j'ai bien compris, c'est bien ce qui se passe avec exec.
Alors que la commande system au contraire est détachée.
 
Concrètement donne moi une raison de passer à boost? C'est plus performant??? c'est plus facile??? (plus facile sûrement pas pour moi vu que je connais déjà un peu pthread et pas du tout boost, donc va faloir que je me refasse chier à linker sur le projet etc).
Le seul problème que j'ai là avec pthread c'est juste concrètement comment déclarer la fonction associée au thread en interne à la classe et pouvoir m'en servir car si hors d'une classe j'y arrive mais en interne c'est le drame.  
 
La concrètement je veux juste savoir si j'ai bien compris ce que fait exec dans mon cas et si elle est bien blocante, si en gros ça fait l'équivalent d'un pthread_create et un pthread_join() ensuite pour parler vulgairement.  
(mais je ne refuse pas défénitivement l'utilisation de boost, juste que j'ai déjà bien avancé, donc si boost ne m'apporte pas grand chose pourquoi y passer, sans compter toutes les fonctions à chercher etc... bref dernier recours ou raison valable)
 
EDIT: je télécharge quand même boost pour voir, car apparement ma méthode a l'air hazbeen
 

Mais bon pour trouver des exemples sur boost ça a l'air assez chiant quoi. Ils montrent juste rapidement comment créer un thread et une valeur partagée entre les thread, mais pas un thread avec paramètre.
Ni comment la mettre en place dans dev c++ etc.  Et ça m'a l'air assez prise de tête.
 
Et pour mon problème de thread il peut se régler comme ça:
http://forum.ubuntu-fr.org/viewtopic.php?id=110404

sauf que la version static est atroce.
Quadn tu telecharge boost, il vient avec un gros repertoire libs/ qui contient les exemples.

Oui j'ai regardé mais dans les exemples, y a pas d'exemple avec un paramêtres, c'est toujours une variable partagée entre les thread et c'est pas ce que je veux.  
Pour le static, oué c'est pas top, mais apparement y a pas d'autres solutions.

bah si ... tu file un constructeur décent à ton foncteur de thread ... ou tu utilises boost:bind ...

Heu oué mais c'est le gros bordel là, y a pas de doc super claire quoi .  
http://www.programmez.com/forum/viewtopic.php?t=1195
 
Je trouve que c'est super fouilli boost.
Pour créer un truc faut faire appel à un autre qu'est pas au même endroit, etc. Y a pas de vrais tutorial ou de doc qui explique clairement. Super quoi.  
Je sens que je vais finir en QT au moins je vais pas me prendre la tête quitte à utiliser une lib.  
 

Je crois avoir compris avec bind.
Mais bon ça n'empèche que je trouve ça super fouillit).
En gros si j'ai une fonction qui demande un paramètre, faut que je fasse:
bind (mafonction,monparm) et que je fasse un thread de ça?
 
Mais après me reste à comment faire toutes les links sous dev c++. Bien prise de tête tout ça quand même.
En sachant qu'il faut que ça soit portable.

C'ets pas fouilli c'ets exhaustif ... et genre boost c'est pas portable
Pour le link, c'est comme n'importequelle biblio tierce, tu renseigne le chemin et basta.

Oué enfin je veux dire, y a pas de vrais doc bien claire et tu fais appel à autre chose quand tu peux pas sans savoir à l'avance que tu peux pas etc.  
C'est pour ça que je veux dire que c'est fouillit.  
Et vu que mon edi ne me liste pas les fonctions
Punaise je viens de rajouter les lib, l' EDI prend un temps fou pour charger toutes les méthodes de boost
J'aurais pas du mettre tout boost
 
PFF ça compile pas je comprends vraiment rien à windows et son édition de lien. C'est chiant ce truc. ça m'énerve.  
Y a pas de lib ni rien je sais pas quoi donner à l'éditeur de lien ni rien.

Je comprends pas, dans le compilateur, je mets, répertoire bibliothèque lib\boost
include: include\boost avec le chemin qui va bien, et je me tapes toujours linker error undefined reference to boost::thread...
 
Je comprend pas et ça commence à m'énerver. Voilà exactement pourquoi je préférais rester avec ma lib qui marchait au moins là j'ai beau mettre ce que je pense qu'il faut mettre ben ça marche pas et comme y a pas de doc ben démerde toi et bien sûr ça marche pas donc j'avance pas.
Y a que des fichiers sources et ça marche pas alors super.*
 
EDIT: super à priori faut que crée moi même la librairie, tu parles de quelque chose d'utilisable oui.

RTFM quand même, Y a un gros Getting Started qui explique comment compiler la lib.

Et bon, les lib source à compilait c'ets le b-a ba du dev logiciel.

Heu oué enfin si c'est pour se prendre la tête autant sous linux tout est bien fait autant pour windows voilà quoi. Pour moi si j'ai un répertoire lib, c'est que la lib y est et pas une foule d'exemple etc. Bref. Vu l'état et vu la prise de tête et comment ça commence sérieusement à m'énerver, je vais faire une pause et je pense vraiment pas utiliser cet "api" qui est trés mal documentée.
 
Oui j'ai vu la doc en anglais pommée à l'arrache mais pour moi c'est pas une doc, une soite de page web comme ça à l'arrache. Désolé.  
Tu vas à compiler, ils te disent faut faire la librairie, pour faire la librairie faut boost.build. Pour boost.build faut bjam et c'est sans fin mince pour moi c'est pas quelque chose de fiable, faut aller le télécharger etc et bjam. Je vais voir si bjam est compatible pour windows mais il n'est même pas inclu dans l'archive. Bref c'est pas viable pour moi un truc comme ça.
 
EDIT/ si il est inclu mais c'est tellement bien expliqué qu'ils te disent de le télécharger.

Je vais basculer sur du QT console avec un vrais EDI au moins ça va pas me prendre la tête et le QT je connais déjà un peu vu que je fais tous mes dev sous linux en QT. Et pas besoin de compiler quelque chose sans doc claire... Et y a les Qprocess etc... + un edi clair et précis. Bref J'avais hésité à basculer sur ça pour un programme assez simple dans l'ensemble mais bon là au moins j'aurais tout sous la main...

Bon, déjà, boost ou pthreads, ici, OSEF, le blem est pas avec les threads, mais avec les process.
 
Mes bases de pthreads sont lointaines, mais clairement, ton besoin est de créer un ordonnanceur de tâches.
 
Alors moi ce que je ferai si j'ai bien suivi ton souci :
* Un thread principal qui surveille le répertoire contenant les fichiers txt
* des threads "de travail" qui seront chargés de lancer et surveiller les tâches
 
En découpant l'algorithme :
Ton thread principal est en boucle infinie (avec un petit wait à 1s par exemple pour pas tout bouffer). Il surveille dans cette boucle :

• La présence de fichier texte. Si un fichier texte est apparu => Création d'un thread via pthread qui va être chargé de gérer la tâche liée à ce fichier texte et à surveiller son exécution
• Si les threads créés ne se retrouvent pas en zombie (en gros, de faire ton "garbage collector"

Tes threads "de travail" vont :

• Ouvrir le fichier texte et lancer la commande via la création d'un processus externe (via l'API Windows CreateProcess ou CreateProcessEx). Ils ont du coup un handle vers ce process, ce qui leur donne accès à toutes les fonctions de l'api sur ce process (tourne t'il encore, le code de retour, etc. Y a une foultitude d'exemple).
• Le thread surveille l'exécution de la tâche, et met en place des mécanismes (kill, alertes diverses email/etc...) quand elle crashe

Tu peux aussi t'en sortir avec un seul thread : ton thread principal fera tout le boulot :
1- surveillance du répertoire et lancement des tâches via CreateProcess
2- Vérification de l'état de chaque process  
 
Le tout dans sa boucle.
 
Moi, je ferai qu'un seul thread si j'ai bien compris ton problème.
 
Fais bien attention à la différence entre thread et processus. ici, tu vas lancer des commandes windows externes à ton programme, en gros des fichiers .exe. Ce sont des programmes autonomes, avec leur propres variables internes, bref, leur propre contexte. Du coup, qui dit contexte séparé, dit Processus, et non pas un thread, qui lui rétilise le contexte de ton programme à toi.
 
En tout cas, ici, clairement, boost, pthread ou autre, c'est un débat qui t'aide pas beaucoup.
 
Pour résumer ma vision des choses :
 
while (1)
{
 If (NouveauFichier) CreateProcess(contenufichier, Handle(NumProcess);
 
For (int i=0;i<Numprocess;i++)
 If (ProcessPlanté(handle[i])) KillProcess(handle[i]));
 
sleep(1000)
}
 
Un truc du genre, tout simplement

D'aillurs, après, le reste de la question se résume à "trouver une fonction CreateProcess qui soit portable". D'après ce que j'ai compris, tu n'as besoin que d'nu truc compatible XP et Vista,  donc API Windows, donc CreateProcess suffit. Si tu veux du linux aussi, là, par contre, je sais pas trop

Oui sur l'analyse j'ai la solution. Si tu veux, j'avais crée une classe application et dans cette classe je met deux threads, un thread avec l'application exécutée recouverte avec un exec, et un timer qui me permet de savoir depuis quand tourne cette application.
ET c'est depuis le main, que je crée X applications (de ma classe) en fonction de ce que j'ai définie, et concrètement j'aurais un tableau déclaré à la Taille X, X étant une constante, et je me sers de sémaphores déclarés à X aussi pour lancer une nouvelle application, je sais pas si je suis bien clair.

Dans mon application principale j'aurais un thread qui est chargé de vérifier tous les X heures la durée de chaque Application et si besoin est de lancer le killage de l'application via une méthode membre de ma classe application. Si tu veux je me crée une classe ou je mets toutes les informations nécessaires (time, numéro de requète, commande à exécuter, si le thread est libre ou pas). Je posterais ma classe.h dès que j'ai le temps. Là faut que je file. Mais j'ai tout pensé et protégé par des mutex et sémaphore au niveaux des variables que j'accède partagées. En gros un thread mais plus poussé avec d'autres informations qui me sont nécessaires pour le programme et au final c'est peut-être con ce que je fais car peut-être que je tends vers un process.

(par exemple si je fais un get de la durée, je protège par un sémaphore pour pas que mon timer interne au programme soit en train de mettre à jour etc).

Bref, la partie du programme est réfléchie et je vois comment la faire, j'avais juste des problèmes du à comment remplacer certaines choses, mais bon là j'aurais des solutions sous QT. Dès que j'ai le temps je vous racontes bien tous mes choix (demain je pense) et j'explique bien tout pour que vous ayez une idée et me dire si mes choix sont logiques ou pas.

QT est mon amis.

Mais je t'expliquerais tout ça demain, pour que tu me dises si c'est bien réfléchie comme il faut. Là je bacle toutes les infos car je dois filer du coup ça doit pas être clair.

Si ça se trouve, je réinvente la roue, et avec qt en utilisant un Qprocess j'aurais pas à faire certaines choses faut que j'analyse bien toute la situation.

 
y a pas a analyser. Qprocess et point.

Je ne suis pas forcément d'accord avec toi au vu de la doc de QT.... Je vais essayer de bien expliquer comment je le vois.
Autant pour le lancement de la commande et juste ça, un qprocess oui c'est possible, mais autant pour ma classe application un thread sera bien plus pratique.
(voir la doc QT pour comprendre pourquoi....) Et j'ai pas de durée de vie de Qprocess, donc ça sera quand même à moi de l'implémenter.
 
Bon je vais vous expliquer comment je le vois.

Bon je reprends le texte de Tetedeiench car c'est quasiment ce que j'avais en vu:
 
Programme principal:
 
Un thread1 garbage collector exécuté toutes les X heures. (Voir plus bas, il se peut que se garbage collector ne soit en fait pas là)
Un thread2 qui listera les différents fichiers présent dans mon répertoire, avec un intervalle définit.
Un thread principal qui est en boucle infinie (avec un petit wait à X minutes par exemple pour pas tout bouffer). il ouvre le fichier texte résultat du thread2 et le parcours avec un sémaphore initialisé à X (X étant ici le nombre maximum de thread voulu). Pour chaque ligne ==>On décrémente le sémaphore puis, Création d'un thread3.
Dans le thread3:  
 Création d'un QThread Application (classe crée à la main qui va être chargé de gérer la tâche liée à ce fichier texte, je lui passe donc en paramètre le fichier texte à ouvrir)
Concrètement, les fichiers qui peuvent être ouvert en simultané seront protégés par des mutex (comme la liste des fichiers à traiter par exemple, quand je liste je bloque avant et débloque aprés et quand je parcours le fichier je bloque avant et débloque aprés)
on attend la fin du QThread
Puis on incrémente le sémaphore
 
Maintenant ma classe application, qui est donc un thread on est d'accord:
il y aura donc des variables internes qui correspondent à ce que je traites dans le fichier, le chemin vers ce fichier, un qtimer pour pouvoir savoir la durée de vie de ma classe application et donc détecter un plantage.
Et un Qprocess pour la commande à éxécuter. (exemple cmd)
Là aussi chaque variable qui peut être mise à jour sera protégée par un mutex, mais bon concrètement, je ne vois pas de concurence d'accés là.
 
 
Maintenant là ou je réfléchie, c'est au niveau de la remontée d'informations. Je pense qu'il est plus judicieux de mettre le garbage collector dans chaque classe application pour gérer son propre qprocess qu'au niveau de l'application principale car ça serait le bordel je pense, mais du point de vue économie d'énergie, ça me semble plus logique que ça soit fait dans le programme principal, mais ça demande une protection par mutex assez chaude, et on peut se dire que chaque application surveille son qprocess.  
 Et bon le Thread 2 et principal peuvent être mis en semble je pense qu'il n'y a pas lieu de les séparer.
 
Donc je pense que le garbage sera plus interne à ma classe application effectivement ça sera bien plus pratique. ça peut tout simplement être un timer initialisé à mon délais et qui tue le qprocess s'il est encore vivant.
 
EDIT: après je vois comment ça va se goupiller pour ne pas exécuter quelque chose que je suis déjà en train d'exécuter (car il ne faut pas que je supprime le fichier de requètes au tout début, sinon si le pc crash, je ne peux plus relancer les requètes.) Mais ça je vois comment faire. Suffit de renomer le fichier en une extension particulière qui dit qu'il est en cours. Et au lancement de l'application je renomme tous ces fichiers là en .trait qui est ce que je traite, comme ça si l'application se crash, je remets en file toutes les requètes qui étaient en cours de traitement. (ça ça n'est exécuté qu'au lancement du programme et c'est une reprise).
Bref je pense que ça roule, faut juste que je gère bien tout. Vous voyez des choses à changer? Des erreurs de réfléxions? des problèmes qui pourraient se poser?

Ben je pense que tu tombes dans le travers du "tout thread". Faut pas oublier que certaines choses peuvent être mutualisées.
 
Pourquoi décorréler la création du fichier txt du thread principal ? Y a pas réellement d'intérêt ici, non ?
 
Pour ton garbage collector, oui, effectivement, ca peut se simplifier à cela.

Oui c'est ce que j'ai mis, la création de la liste des fichiers à parcourrir et le parcours de ce fichier peut être dans la même boucle. La y a pas besoin de rajouter un thread, c'était ma remarque en me relisant.  
Tu ne vois pas de choses à améliorer ou de mauvais choix techniques?
Pour le timer ça me semble être la bonne idée car il peut être arrété avant l'exécution d'un "tic d'horlge" et donc ça correspond bien.
Le seul endroit ou il faut que je gère bien c'est sur les fichiers au niveau du renommage etc. Et bien attendre la fin des process et que tout soit bien organiser, mais je pense que ça va si j'ai fais les bon choix techniques.

Punaise, c'est pas vrais j'ai pas de chance, à croire que tous les EDI sous windows sont buggés. je prends QT creator et il marche pas.
 
Mon dieux que je regrettes de pas être sous linux, au moins y a des EDI gratuits fonctionnels.

Code::Blocks marche très bien sous windows  hein