[C++] Stopper une fonction or de celle-ci

Bonjour,

Je cherche à arrêter une fonction en étant or de celle-ci, donc je ne peux pas utiliser la commande break;. Or j’ai testé break(calculate()); mais ça ne marche pas. Existe-t-il un moyen de faire cela ?

PS : C’est une appli Qt mais là c’est plus du C++ en lui-même.

Salut

Donc, tu voudrais appeler une fonction, celle-ci tournerait en tâche de fond, et l’appelant continue son traitement puis il avise d’arrêter la fonction appelée. C’est bien cela ?

Et bien, ce n’est pas possible tel quel avec C++.

Il faut soit faire du fork ou bien un nouveau thread. Avec tout ce que cela implique point de vue accès concurrentiel, mutex ou sémaphore, partage mémoire, contrôle d’exécution…

Ou bien revoir le design de ta solution. IPC (InterProcess Call) ? Application via port réseau ? Utilisation de socket Unix ? Service ou daemon ?

De plus, je vois que tu poses bcp de question point de vue coding. Je pense que tu es débutant. Donc, je te conseillerais des lectures dans ce domaine. Un premier départ pourrait être developpez.com ou openclassrooms.com. Essaie de t’intéresser aux différents paradigmes du développement informatique.

Hey !

En fait je voudrais que quand je cliques sur mon bouton, qui est connecté au slot stop(), ça arrête l’exécution de la fonction calculate(). Le problème c’est que j’ai pensé à une variable qu’on vérifierait à chaque tour de boucle, mais ça ralentirait le calcul.

Aussi, ça fait depuis 2 ou 3 ans que je code en Qt mais jusque-là je n’avais pas été confrontés à ces problèmes, et j’ai appris grâce à OpenClassrooms, au Livre du Zéro plus précisément quand c’était l’époque du Zéro. Mais bon maintenant je suis converti à la wiki-manie :slight_smile:

Du coup les trucs de Thread j’ai jamais rien compris à ça.

Bonjour,

J’ai mis un exemple ICI

L’idée, c’est :

  • une variable boléenne à portée globale
  • on lance une boucle (un appui sur une touche est détectée et la variable booléenne change d’état)
  • on lance calculate() qui DOIT se terminer si la variable booléenne a changé d’état
  • l’appui sur une touche donnée est détectée, et la variable booléenne change d’état
  • le changement d’état est détecté dans calculate() qui se termine.

En fait, il faudra adapter le code à Qt, mais je n’utilise pas cette API. La licence ne n’intéresse pas, et surtout TrollTech se moque des petits développeurs et à un intérêt de moins en moins … disons présent pour les petits développeurs (comme moi).

En espérant avoir aidé.

Merci c’est en effet la solution que j’avais envisagé, mais mon objectif est de ne pas « gêner » les calculs et donc d’arrêter or de la fonction, pour calculer le plus rapidement possible. Si besoin je peux envoyer le code source.

L’arrêt est bien déclenché « hors » de la fonction calculate()

Peut-être ai-je mal expliqué : à chaque tour de calcul, calculate() vérifie que b_quit n’a pas changé d’état. Quand b_quit a changé d’état, calculate() s’arrête toute seule, à la fin de la boucle.

Pour mémoire, c’est la boucle qui tourne dans un coin qui effectue le changement de valeur de b_quit.

P.S. : pour le code, je suis désolé, mais je suis déjà sur un truc compliqué. AMHA, tu devrais y arriver facilement.

Oui c’est ça, mais le problème c’est qu’il vérifié DANS la boucle, or ça va influencer sur les calculs parce qu’à chaque nouveau nombre on va devoir vérifier la valeur, ce qui fait perdre quelques millisecondes mais plusieurs minutes quand on calcule beaucoup de nombres.

Là, je suis en train d’enregistrer du son (callback) et de la vidéo (openCV + webcam à ~ 24 fps) en parallèle et ça fonctionne très bien.

Elle calcule quoi ta boucle ?

Elle calcule des nombres premiers (l’utilité est à revoir).

Dans ce cas, je suggère de bien réfléchir au fonctionnement AVANT de coder. Sinon, ça risque d’être bancal.

Bonne continuation :slight_smile:

Oh t’inquiète j’ai déjà réfléchi puisque j’ai déjà publié la première version hier. Sauf qu’on ne pouvait pas stopper en cours de route. :wink:

Le code il est là @ericb : https://github.com/AirSThib/Primus

Bonjour,

Je n’ai pas regardé le code, mais, au vu de ce que j’ai compris des discutions, l’interface graphique doit être figée lors des calculs. Pas terrible comme comportement et point de salut hormis l’utilisation d’un thread.
Les threads, c’est pas si terrible que ça. En gros, c’est une fonction qui s’exécute en parallèle du reste du programme. Là où il faut faire attention, c’est lorsqu’on échange des données entre les threads.
Attention aussi au fait qu’en général, les fonctions de l’API d’une interface graphique ne peuvent être appelées qu’à partir du thread principal. Sinon… tout peut arriver.
En cherchant Qt et thread sur le net, il doit bien y avoir des exemples à la pelle.

Nicolas

Bonjour,

Le problème des threads, c’est qu’il faut faire le plus simple possible, et donc avoir un code bien factorisé, pour éviter les sacs de noeuds (j’ai passé 3 mois à trouver un double free avec un thread qui donnait un dead lock avec ffmpeg …)

Par ailleurs, je ne sais pas si Qt est le bon choix en ce moment*. Plutôt utiliser pthread, ou simplement la libstdc++ standard (sdt::thread etc) ou encore boost qui me semble plus pérennes que Qt.

*Pour illustrer mon propos : https://www.phoronix.com/scan.php?page=news_item&px=Qt-5.15-LTS-Commercial-Phase (ça date d’aujourd’hui même, mais on le sait depuis longtemps).

Pour rmes applications, je ne regrette pas d’avoir choisi Dear ImGui + OpenGL** + SDL2.

**(puis Vulkan, qui fonctionne déjà et remplacera OpenGL à terme)

Ahhh, @ericb se dévoile de plus en plus :slight_smile: Je ne connaissais pas Dear ImGui et tu as attisé ma curiosité. C’est très vilain! Vu le nombre de choses auxquelles je m’intéresse, je vais plus avoir du temps pour rien :slight_smile: D’ailleurs, j’ai trouvé un article sur développez.com à propos de cette lib. C’est écrit par un certain ericb2. Un cousin, je suppose :slight_smile:

Non non, c’est pas mon cousin, c’est moi aussi :slightly_smiling_face:

Si ça t’intéresse, j’ai écrit quelques billets de blog sur ce même développez.com. Mais j’ai pas trop le temps en ce moment (bientôt, je terminerai la partie 4 sur le canvas en C++)

Et si la physique t’intéresse, j’ai mis plein de chose sur framagit aussi

C’est vrai avec n’importe quel programme. Thread ou pas.

Thread ou pas thread, ce genre de bug arrive.

Il existe WxWidgets qui est très bien. Et tu n’auras pas les problèmes de licence de Qt.

Si tu ne fais pas de multi-plateforme linux/windows, utilises les fonctions natives. Sauf s’il y a un vrai intérêt à utiliser une surcouche.
Boost… Dans le genre sac de noeud… C’est la première chose que je fuirais. C’est un énorme amas de code divers et variés. Ca prend des plombes à compiler. Des choses apparaissent, disparaissent… C’est un peu l’antichambre de ce qu’il y aura dans les futures normes C++. Ce qui y est expérimenté et validé passera peut-être dans une future norme.

Je pense que ton soucis vient de la gestion de l’evenement buttonClick… Tu as besoin pour ton bouton deux états différents: calculate et stop… A chaque click il change l’etat, Tu peux le gérer avec une seule fonction dans la classe MainWindow disons private void myButtonClick() … Tu auras besoin un variable boolean disons btnEtat dans MainWindow.

Dans la constructeur de la class :

private boolean btnEtat= true;

connect(buttonCalculate, SIGNAL(clicked()), this, SLOT(myButtonClick()));

Ensuite dans
void myButtonClick(){
if(btnEtat)
calculate();
else
stop();
}
Bien entendu il faut changer la valeur de bntEtat à chaque click et faire les modifications necessaire dans tes functions acteulle calculate() et stop()

Après la réflexion la solution consistera d’utiliser d’un thread qui peut recevoir un signal… Car le signal btnClicked n’a pas une priorité