Discussion :

[oodini]

Hello,

Comment faire en sorte que ce qui est envoyé vers std::cout ne soit pas affiché ?

[pyros]

> /dev/null ?

[jblecanard]

Il est possible de le faire en C++ !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

std::cout.clear(std::ios::failbit);

Et plus rien ne s'affichera sur ce qui part dans std::cout.

[6-MarViN]

Tu met la ligne ou tu utilise std::cout en commentaire.

[oodini]

Je n'ai pas accès à la ligne en question.

Les sorties écran sont générées par une bibliothèque externe.

[therwald]

lib statique ou dynamique? Est-ce que dans la lib ce sera le même std::cout que côté appelant ou pas? std::cout c'est une sorte de variable statique, non?

[oodini]

Dynamique. Je pense que c'est le std::cout standard.

[therwald]

as-tu essayé la solution proposée par jblecanard?
la raison pour laquelle je demandais pour le linkage est qu'à mes yeux std::cout ressemble fort à un objet statique, et je me demandais si dans ce cas pour une lib dynamique on n'aurait pas dans la lib sa propre instance std::cout qui serait insensible à ce qu'on fait à std::cout côté exécutable...
sinon effectivement rediriger stdout vers /dev/null devrait fonctionner sous *nix, je me demande s'il existe un équivalent windows?

[oodini]

as-tu essayé la solution proposée par jblecanard ?

Non, j'avais raté sa réponse !

[oodini]

Il est possible de le faire en C++ !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

std::cout.clear(std::ios::failbit);

Et plus rien ne s'affichera sur ce qui part dans std::cout.

Je savais bien qu'il devait exister quelque chose dans ce goût là.

Donc, avant d'appeler les fonctions de ma bibliothèque qui génèrent les sorties écran indésirables, j'appelle l'instruction que tu as données, et juste après, j'appelle :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

std::cout.clear(std::ios::goodbit);

pour rétablir le fonctionnement normal.

C'est bien ça ?

[jblecanard]

Oui, c'est ça ! Ca présente un inconvénient tout de même : ce qui est envoyé dans std::out est évalué, par exemple, si tu désactives l'affichage, et que tu appelles :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

std::cout << f(3);

f(3) sera évalué, bien que rien ne soit affiché. La question du linkage de la lib est pertinente. Il se peut que ça ne fonctionne pas à cause de ça... Une seule solution pour savoir : essayer.

> /dev/null ?

Au delà du simple fait que ça ne fonctionne que sous Unix, ça ne donne aucune granularité à oodini qui veut bloquer les sorties d'une lib (et pas les siennes par exemple).

[JolyLoic]

Même si le failbit doit marcher, il ne s'agit pas vraiment d'une redirection (les sorties vont échouer, plutôt que d'être redirigées) et ça ne me semble pas hyper robuste (et si le code en question fait du if (!cout), certes peu probable ?).

A mon avis, une solution à base de rdbuf est plus safe (et on peut même récupérer ce que l'application tierce a écrit, pour l'analyser par exemple). Voir un exemple sur http://www.cplusplus.com/reference/iostream/ios/rdbuf/ .

[oodini]

De toute façon, ma question est peut-être caduque, car on vient de m'apprendre que ladite bibliothèque est codée en C.

Je ne pense pas qu'intervenir sur les flux ait une quelconque influence.

[therwald]

Arf! Mais si elle est écrite en C, elle a des flux aussi, simplement ils ne sont pas gérés avec std::cout...
Quelqu'un qui connaît C saura peut-être si on peut écrire un code permettant de museler stdout de manière à ce que le code C ne puisse pas écrire dedans (mais sans que ça plante...)?
EDIT: peut être moyen d'utiliser +/- ça:
http://www.cplusplus.com/reference/c...stdio/freopen/

[therwald]

bon, c'est pas une solution finie, là, vu que le chemin pour revenir à l'état antérieur n'est pas tout tracé...