Discussion :

[Charlemagne]

Bonjour

Je suis débutant en .NET.
Je compte commencer bientôt un programme avec ".NET" sous VC 2008 (Express).

Je pense le faire en C++, mais je n'ai pas trouvé de forum C++ dans la rubrique ".NET", alors je poste ma question ici. Il ne devrait pas y avoir de différence sur le fond.

L'IHM de mon programme doit mettre à jour l'affichage d'une image vidéo en attendant les ordres et les clics de l'utilisateur.
Je vois la possibilité de faire un thread, mais ça ne m'enthousiasme pas du tout à cause des difficultés qui ne manqueront pas de venir pour la synchronisation lors des actions de l'utilisateur.

Alors je me demandais si il n'y avait pas la possibilité de se passer d'un thread????
Par exemple s'il y a une fonction virtuelle appelée régulièrement par l'application principale... ou autre chose...

Merci d'avance

[ZaaN]

Si tu veux vraiment te passer d'un thread (chose que je ne te recommande pas du tout dans ce cas!) , tu peux le faire sans problème. Au risque de bloquer ton application bien sur !

Mais c est une mauvaise conception que celle là.
Professionellement un IHM pareil est inacceptable ( en tout cas dans tous les domaines ou la sécurité/fiabilité demandé est differente de nulle)

[Charlemagne]

J'essaye juste de me simplifier la vie.
Les threads sont toujours bordéliques à synchroniser (mutex, etc...)

Tu dis que c'est faisable sans problème, comment donc??????
Je ne compte pas bloquer l'application, bien sûr. (par exemple en gardant la main lors le l'initialisation)

J'espère une sorte de fonction virtuelle appelée régulièrement par l'IHM.
Si une telle fonction existe, je la surchargerais et la quitterais dès que le rafraichissement vidéo serait accompli.
L'avantage serait que je pourrai être sûr qu'il n'y aura aucun conflit de threads (je n'aurai que le thread principal) lorsque l'utilisateur exécutera une action.

[ced600]

Tu dis que c'est faisable sans problème, comment donc??????
Je ne compte pas bloquer l'application, bien sûr. (par exemple en gardant la main lors le l'initialisation)

peux le faire sans problème. Au risque de bloquer ton application bien sur !

Je pense le faire en C++, mais je n'ai pas trouvé de forum C++ dans la rubrique ".NET"

Du c++.Net c'est du C#.
On dit souvent que C# est comme Java, mais c'est faux, c'est juste que c'est deux langages ce sont inspirés du C++.
Après comme tu es dans du code managé pas de malloc, pas de pointeur, tout est géré par le framework.
En fait faire du .net c'est apprendre à utiliser le framework, après une syntaxe ou une autre, on s'en fou un peu, sauf que C# sur le CV rend fou de joie les recruteurs, bien plus que VB.net par exemple.

[ZaaN]

Les threads sont toujours bordéliques à synchroniser (mutex, etc...)

Avec le baggage théorique relatif, tu remarquera que c'est pas bordélique la programmation concurente. C'est juste une autre manière de penser.

Note qu'en C#, dans une utilisation standard, la synchronisation peut etre réalisé avec Lock et Unlock. Le méchanisme se base sur les moniteurs, mais tout est encapsulé et tu n'as pas à faire la gestion toi meme.

[Charlemagne]

Mais j'aimerais voir si y une alternative au thread.
Faire un thread à tout prix n'est pas forcément la meilleur solution.

Personne ne voit d'alternative?

Si tu veux vraiment te passer d'un thread (chose que je ne te recommande pas du tout dans ce cas!) , tu peux le faire sans problème

Comment donc??? c'est ma question depuis le début.
J'aviserai des risques plus tard...

[ced600]

Mais j'aimerais voir si y une alternative au thread.
Faire un thread à tout prix n'est pas forcément la meilleur solution.

Personne ne voit d'alternative?

Comment donc??? c'est ma question depuis le début.
J'aviserai des risques plus tard...

Je pensais qu'en mettant les deux citations l'une ne dessous de l'autre, tu allais comprendre ce qu'il a voulu dire, mais non apprement.
J'explique ce que j'ai compris :
L'autre moyen c'est de tout faire dans le thread principale.
Et du coup ton ihm à de grande chance de freezer.

[Charlemagne]

Je pensais qu'en mettant les deux citations l'une ne dessous de l'autre, tu allais comprendre ce qu'il a voulu dire, mais non apprement.
J'explique ce que j'ai compris :
L'autre moyen c'est de tout faire dans le thread principale.
Et du coup ton ihm à de grande chance de freezer.

et moi j'avais répondu ça

Je ne compte pas bloquer l'application, bien sûr. (par exemple en gardant la main lors le l'initialisation)

J'espère une sorte de fonction virtuelle appelée régulièrement par l'IHM.
Si une telle fonction existe, je la surchargerais et la quitterais dès que le rafraichissement vidéo serait accompli.
L'avantage serait que je pourrai être sûr qu'il n'y aura aucun conflit de threads (je n'aurai que le thread principal) lorsque l'utilisateur exécutera une action.

Une fonction virtuelle dans le genre, ou un mécanisme similaire existe t-il?

[theMonz31]

salut

a defaut de thread, tu peux toujours faire un timer

The Monz, Toulouse

[SaumonAgile]

a defaut de thread, tu peux toujours faire un timer

Ce qui bloquera de toute façon l'application.

Charlemagne : Pourquoi t'obstiner à éviter les threads ? c'est la solution la plus propre et la plus efficace. Là, tu es en train de nous demander de te trouver une solution sale parce que tu n'as pas envie d'utiliser des threads. Il ne faut pas espérer une réponse pertinente alors que ta question ne l'est pas.

Tu peux utiliser par exemple un backgroundworker qui te masque une partie de la soit-disant complexité des threads.

[Charlemagne]

Charlemagne : Pourquoi t'obstiner à éviter les threads ?

Parce que j'ai vu (et je vois) des programmes avec des threads, conçus par des informaticiens soit disant expérimentés. Ces programmes sont bugués jusqu'à la moelle.
Et si je peux m'éviter des synchronisations fastidieuses, j'aimerais bien le faire.
Les informaticiens dont je parle auraient mieux fait d'y penser avant de faire des threads à tours de bras.

Un timer bloquerait effectivement l'application de toute façon.

Visiblement personne ne connait une fonction virtuelle miracle à surcharger... tant pis...

[SaumonAgile]

Visiblement personne ne connait une fonction virtuelle miracle à surcharger... tant pis...

Le concept de méthode virtuelle n'a absolument rien à voir avec les threads et les problèmes de concurrence. Tu mélanges plusieurs notions. Avant de t'attaquer à ce problème de thread, tu devrais jeter un oeil sur les concept de POO, histoire de repartir sur de bonnes bases.

[ced600]

Le concept de méthode virtuelle n'a absolument rien à voir avec les threads et les problèmes de concurrence. Tu mélanges plusieurs notions. Avant de t'attaquer à ce problème de thread, tu devrais jeter un oeil sur les concept de POO, histoire de repartir sur de bonnes bases.

Cela attaque sec

Mais bon il a raison, tu ne sembles pas avoir de bonne base.
Je te conseil aussi de lire de la doc sur les threads en C# car apperement tu ne sais pas trop ce que c'est, on a l'impression que pour toi le multithreading c'est une piece noir avec une porte sur laquelle on peut lire : Taboo.

Et si tu montes en compétence sur ces points, tu pourra faire du multithreading sans trop de problème, correctement, et tu obtiendras un programme non bugues.

Une méthode miracle : On n'a pas, tu peux toujours t'agenouillé et prier, peut être qu'il te donnera l'inspiration

[SaumonAgile]

Juste pour préciser, le ton que j'employais n'était pas agressif, même si certains ont pu avoir cette impression.
Je tenais simplement à mettre quelques idées au clair.

[Charlemagne]

Je me casse...
Certains n'essayent même pas de comprendre ma philosophie. Si vous ne voyez pas d'alternative à un thread: dites le.

Au lieu de ça on prétend que je n'ai les bases, et que je confonds threads et fonctions virtuelles, etc.
Je débute en ".NET" mais pas en C++.
Vous devez faire partie de ce genre de programmeurs que j'évoque plus haut.

[ZaaN]

mais LOL !!!

Si vous ne voyez pas d'alternative à un thread: dites le.

tu as toutes les info : il existe des alternatives sales precitées ci dessus !

Au lieu de ça on prétend que je n'ai les bases, et que je confonds threads et fonctions virtuelles, etc.

c'est bien le cas vu tes réponses !

Je débute en ".NET" mais pas en C++.

les concepte POO et prog concurrente restent les memes pourtant !

Je me casse...
Certains n'essayent même pas de comprendre ma philosophie.
Vous devez faire partie de ce genre de programmeurs que j'évoque plus haut.

le mieux est de fermer ce post et d'ouvrir tes bouquins !

[Penguin]

theMonz31 : a defaut de thread, tu peux toujours faire un timer

Ce qui bloquera de toute façon l'application.

Pas forcément, si son traitement lors de l'appel du timer est assez rapide.

De plus, s'il veut modifier des propriétés de la fenêtre (pour afficher un texte ou une image), il devra de toute façon le faire dans le thread dans lequel la fenêtre a été créé (via invocation si nécessaire).

Dans son cas, le thread n'est pas forcément la solution. Il faudrait avoir plus de précision sur les traitements qu'il veut effectuer pour déterminer la meilleure solution

[SirJulio]

Du calme, messieurs ! =)

Pour repondre à l'OP, le threading sous C# est plus simple à mettre à place que sous C++, (entre le statement lock, les type delegué etc, ca peut se faire assez facilement). Si neanmoins, tu veux te masquer la difficulté, et si le design est adapté, tu peux tout à fait passer par un timer (un timer est par essence threadé, ca ne bloquera pas l'appellant).

Mais de toutes facons, pour un traitement lourd avec un gui, tu ne pourras pas eviter l'utilisation d'un ou de threads qu'elle soit explicite (Thread t = etc ...) ou non (Timer, BeginInvoke etc ...).

Bon courage.

[ced600]

Je débute en ".NET" mais pas en C++.

Justement .Net et c++ non rien à voir en dehors de la syntaxe.
Demande au développeur en vb6, ils se sont fait avoir en passant au vb.net

Le .net c'est apprendre à utiliser le framework.

L'architecture d'un logiciel en POO n'a jamais était dépendant d'un langage lui, juste dans la dernière étape de conception où tu dois potentiellement l'archi de certains composant pour prendre en compte les spécificités du langage.