fenetre "texte" genre console
cyrano
Membre
bonsoir,
j'ai une application c++ (monothread) en mode console (les sorties se font par std::cout).
desirant passer au multithread, les sorties se melangent dans la console (plas glop).
quel est la meilleure solution pour creer une sortie pour chaque thread. une fenetre "texte" par thread est l'ideale. On doit sortir l'api cocoa et obj-c pour cela (que je ne connais pas) et interfacer avec mon code c++ ?
merci de vos sugestions
j'ai une application c++ (monothread) en mode console (les sorties se font par std::cout).
desirant passer au multithread, les sorties se melangent dans la console (plas glop).
quel est la meilleure solution pour creer une sortie pour chaque thread. une fenetre "texte" par thread est l'ideale. On doit sortir l'api cocoa et obj-c pour cela (que je ne connais pas) et interfacer avec mon code c++ ?
merci de vos sugestions
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
T'es bon pour nous offrir une tournée générale, c'est la règle iciÂ
Allez hop hop hop
----
Bon, pour ton problème, oui tu peux créer une interface graphique pour interfacer ton code C/C++, et remplacer tes std::cout par des appels à des méthodes Cocoa qui vont rajouter le texte dans la fenêtre adéquate. C'est le plus simple.
Mais si tu ne connais pas Cocoa et n'en a jamais fait, entre autres que tu n'as jamais touché à InterfaceBuilder, ça ne va pas forcément te sembler évident au premier abord. Alors qu'en soit c'est pas bien méchant
----
Autre solution, pure-C
Sinon côté C++-only, moi je m'orienterai vers les pipes nommées (named pipes), qui me semble une solution assez simple.
Tu crées tes pipes nommés (fichiers) pour la sortie (avec "mkfifo", dans le Terminal ou en code C au choix), une pipe par thread.
Ensuite chaque thread écrit dans le pipe qui lui est associé (à la place de ton std::cout), comme ça tu écris dans des flux séparés
Après pour voir chaque sortie, tu ouvres une fenêtre terminal par thread, et tu tapes "cat nomDuFichierPipeNomméQueTuVeuxLire". et ça va lire en direct, en affichant le texte au fur et à mesure qu'il arrive.
C'est bien différent que d'écrire dans un simple fichier régulier (séquentiel) car dans le cas de pipes, le "cat" va toujours attendre de nouvelles données et non pas s'arrêter à la "fin" du fichier (un tube n'est pas un fichier séquentiel, il n'a pas de "EOF")
En plus en C c'est pas dur à faire :
Un programme à la con pour te montrer (j'ai utilisé fopen plutôt que open car je trouve que c'est plus simple à manipuler, avec fprinttf & co ça facilite les choses)
Ce bout de code montre juste comment très simplement remplacer tes std::cout par un simple sprintf. Note : avec ce code j'ai ouvert les pipes en mode bloquant (mode par défaut), donc les lignes fprintf vont bloquer le programme tant que les pipes ne seront pas lues et vidées (quel que soit le moyen, code C ou directement dans le terminal). Si tu ne lis pas les flux, le code ne continuera pas.
Si tu veux du non-bloquant, utilises plutôt open et les flag O_WRONLY|O_NONBLOCK
Bon, il te suffit de compiler ce code avec gcc, puis tu ouvres 4 fenêtres terminal : 1 par pipe que tu veux lire (qui seront les sorties de tes threads dans ton code final), et un pour lancer l'appli.
dans un premier temps, je vais implementé les named pipes (simple et rapide a mettre en oeuvre). je n'abandonne pas l'idee de le faire avec cocoa.
passes prendre un verre
j'ai lu dans ta bio que tu as fait du Qt, qu'en penses tu par rapport a cocoa quand on programme en c++.
- Je trouve ça quasi aussi sympa que Cocoa côté "approche de programmation"
- Par contre c'est pur C++ (y'a des ponts possibles mais c'est C++ à la base), alors que Cocoa c'est Objective-Cocoa. Les concepts ne sont pas les mêmes (messages envoyés aux objets, outlets, ... contre signals et slots)
- L'approche est un peu différente mais ni mieux ni meilleure, chacune se vallent
- Par contre le framework QT, bien que très complet, l'est moins que Cocoa
- Mais en contrepartie il est cross-plateform
Donc c'est kifkif.
Moi si je fais du Cocoa, c'est pour avoir des applis intégrés à OSX, et pour pouvoir utiliser Cocoa (dans toute son intégration à OSX)
Mais si j'ai à faire du C++ en crossplateform, j'utilise QT.
Fayot ! :kicking:
Cocoa, ce ne serait pas plutôt Objective-C?
on m'a conseillé, un simple fichier texte et la cmd tail -f.
encore plus simpleÂ
Pourquoi faire simple quand on peut faire compliqué, hein ?