Discussion :

[fanjoe31]

j'aimerai savoir la démarche comment on programme dans une fenêtre standard :

"appuyez sur une touche pour fermer la fenêtre . . ."

merci d avance !

[koala01]

Salut,

La question a été posée si souvent que l'on en a fait une entrée de la FAQ

[cob59]

Je sens que si je propose system("pause"); je vais me faire incendier... mais ça répond plus précisément à sa demande.

[koala01]

Je sens que si je propose system("pause"); je vais me faire incendier

Effectivement

L'instruction system a les énormes inconvéniants

1. D'être totalement dépendant du système sur lequel l'application est lancée, et donc totalement non portable (tu n'es jamais sur que l'instruction système que tu appelle sera fournie par l'ensemble des systèmes sur lesquels ton application risque de fonctionner)
2. de faire appel à... une instruction système, ce qui demande énormément temps et de ressources

... mais ça répond plus précisément à sa demande.

Absolument pas, pour les raisons que je viens de citer

La FAQ fournit une solution simple, élégante, fiable, portable et ne faisant appel qu'à du C++ pur d'y arriver... Pourquoi s'en priver

[cob59]

1. On peut choisir de faire un code non-portable si l'on est certain que celui-ci tournera exclusivement sur Windows. La portabilité est une garantie, pas une obligation !
2. Quel intérêt d'économiser le temps d'exécution d'une instruction qui sert justement à l'interrompre, en attendant (souvent plusieurs secondes) la réaction de l'utilisateur ?
3. <mauvaise foi>J'ai remarqué que system("pause") et la solution proposée dans la FAQ n'étaient pas exactement similaires : l'une réagit à l'appui de la touche ENTREE et l'autre à l'appui de n'importe quelle touche. Donc system("pause") répond plus précisément à sa requête.</mauvaise foi>

[koala01]

On peut choisir de faire un code non-portable si l'on est certain que celui-ci tournera exclusivement sur Windows. La portabilité est une garantie, pas une obligation !

jusqu'au jour où...

C++ est un langage standardisé par un organisme international...

Respecter la norme qui en régit les bases te donne de bien meilleures garantie de comportement et de reproductibilité que tout ce qui se trouve "en marge" de la norme et qui dépend donc uniquement du "bon vouloir" d'une équipe d'implémentation.

Tu n'es en effet jamais sur que ces comportements "à la marge" seront reproductibles dans la version suivante

La portabilité n'est pas uniquement un problème de système d'origines différentes (ex : window Vs linux), mais aussi un problème de système d'origines identiques mais de versions différentes (ex: Win XP Vs seven ou vista)

Quel intérêt d'économiser le temps d'exécution d'une instruction qui sert justement à l'interrompre, en attendant (souvent plusieurs secondes) la réaction de l'utilisateur ?

Cela parait paradoxal, hein?

Mais, outre le temps d'exécution, il faut te dire qu'il y a aussi le problème des ressources que cela demande... tu sembles avoir "zappé" trois mots dans ma deuxième raison

<mauvaise foi>J'ai remarqué que system("pause") et la solution proposée dans la FAQ n'étaient pas exactement similaires : l'une réagit à l'appui de la touche ENTREE et l'autre à l'appui de n'importe quelle touche. Donc system("pause") répond plus précisément à sa requête.</mauvaise foi>

C'est effectivement de la très mauvaise foi, car il, quelque part, dangereux de laisser faire en sorte que n'importe quelle touche puisse permettre de mettre fin à la pause

[cob59]

Alors on viole une norme en utilisant les fonctions de cstdlib ?
On en apprend tous les jours

Peux-tu m'indiquer les versions de Windows où "pause" n'est effectivement pas disponible ?

[pyros]

Juste pour mettre mon grain de sel, je pense qu'une personne comme fanjoe31 qui en est à se demander comment récupérer une entrée clavier de l'utilisateur est loin, mais alors très loin de se poser des questions sur la portabilité de son code

[koala01]

Alors on viole une norme en utilisant les fonctions de cstdlib ?
On en apprend tous les jours

Non, system est une instruction portable, c'est l'instruction système qui sera appelée qui ne l'est pas forcément.

Avec system, tu peux appeler n'importe quelle fonction système, or, il y en a qui n'existent que sur un système particulier (ou sur une / des version(s) particulière(s) d'un système)

Je ne dis rien de plus que cela

Peux-tu m'indiquer les versions de Windows où "pause" n'est effectivement pas disponible ?

Dois-je te rappeler que windows 3.xx et windows 95 (peut etre aussi 98) étaient des surcouche lancée après DOS, et que DOS n'existe plus depuis XP, échangé par l'invite de commande qui ne fait qu'en émuler certains comportement

Va savoir, à partir du moment ou pause n'existe que par la volonté des développeurs de windows, si elle existera toujours...

En attendant, la durée de vie moyenne d'un système d'exploitation est de trois ans, et sa durée de support moyenne est de six...

C'est à dire beaucoup moins importante que la durée de vie moyenne d'une application professionnelle

[pyros]

En attendant, la durée de vie moyenne d'un système d'exploitation est de trois ans, et sa durée de support moyenne est de six

Un peu pessimiste quand même... Microsoft va arrêter le support d'XP en 2014, pour un OS sortie en 2001 ça lui fait déjà une belle vie. Et il y a encore beaucoup d'XP encore utilisé aujourd'hui.
Je ne parle pas des OS mort-né comme Windows ME ou Vista, mais windows 7 a bientôt 3 ans et ne risque apparemment pas d'être détronné par windows 8. Une génération ne correspond pas à une durée de vie. Heureusement, sinon on mourrait tous à 25 ans

Cette durée de vie de 3 ans correspond plus a un certain public technophile accro aux nouveautés, une entreprise ne peut pas se permettre de mettre à jour son parc informatique tout les 3 ans...

Pour le problème de la portabilité, les arguments de koala01 sont tout à fait valable. A partir du moment ou on utilise une fonctionnalité qui n'appartient à aucune norme ou qui est spécifiques à un produit (ce qui est le cas de beaucoup d'appel système), rien ne garanti qu'elle sera disponible ailleurs.

Cependant, on n'a pas toujours envie de faire un logiciel portable. La portabilité coûte chère, et le respect des normes ne la garanti pas totalement. Il garantit juste que les problèmes viennent de la plateforme et pas de nous (bug d'implémentation, non-respet des normes etc...), mais vas expliquer ça à un client... Si la cible principale est la ménagère de moins de 50 ans, on peut se contenter de tester le produit sur XP et 7. Il est inutile (peu rentable) de se fatiguer à le rendre compatible sous unix ou de prévoir sa compat avec windows 8.

[koala01]

Un peu pessimiste quand même... Microsoft va arrêter le support d'XP en 2014, pour un OS sortie en 2001 ça lui fait déjà une belle vie. Et il y a encore beaucoup d'XP encore utilisé aujourd'hui.

C'est l'exception qui confirme la règle, et c'est uniquement du au fait que microsoft avait sous estimé l'engouement qu'il y aurait pour les processeurs 64 bits

Je ne parle pas des OS mort-né comme Windows ME ou Vista, mais windows 7 a bientôt 3 ans et ne risque apparemment pas d'être détronné par windows 8. Une génération ne correspond pas à une durée de vie. Heureusement, sinon on mourrait tous à 25 ans

Et pourtant...

Tu je te fiche mon billet que, dans les trois ans, le successeur de windows sera sorti, et que le support de seven s'arrêtera peu de temps après

Cette durée de vie de 3 ans correspond plus a un certain public technophile accro aux nouveautés, une entreprise ne peut pas se permettre de mettre à jour son parc informatique tout les 3 ans...

Le problème, c'est que meme les entreprises n'ont pas forcément le choix :

A partir du moment où le support n'est plus fourni, entre autres pour les problèmes de sécurité, une entreprise n'a plus vraiment d'autre choix que de... passer à une version suivante...

Pour le problème de la portabilité, les arguments de koala01 sont tout à fait valable. A partir du moment ou on utilise une fonctionnalité qui n'appartient à aucune norme ou qui est spécifiques à un produit (ce qui est le cas de beaucoup d'appel système), rien ne garanti qu'elle sera disponible ailleurs.

Cependant, on n'a pas toujours envie de faire un logiciel portable. La portabilité coûte chère, et le respect des normes ne la garanti pas totalement. Il garantit juste que les problèmes viennent de la plateforme et pas de nous (bug d'implémentation, non-respet des normes etc...), mais vas expliquer ça à un client... Si la cible principale est la ménagère de moins de 50 ans, on peut se contenter de tester le produit sur XP et 7. Il est inutile (peu rentable) de se fatiguer à le rendre compatible sous unix ou de prévoir sa compat avec windows 8.

Tout dépend de la durée de vie que tu prévois pour ton programme...

ce qui est sur, c'est que cela prend à peine vingt secondes de plus de faire une pause portable par rapport à l'utilisation de system("pause")...

Ce qui est sur aussi, c'est que la pause portable fonctionnera, comme son nom l'indique, partout.

Nous sommes donc clairement dans le cas où le respect de la norme ne coute finalement pas grand chose, mais apporte une garantie que l'alternative n'apporte pas.

Et, si je parle ici d'un cas particulier, il faut te dire que, de manière tout à fait générale, le principe reste le même pour tout

[Bousk]

Bonjour,

pour rester dans le lynchage, je propose tout de même l'option -w sur visual (propriétés du projet>debugging>command arguments)

Blague à part, la portabilité c'est bien, mais l'essentiel reste de correspondre à son besoin. Dans ce cas on ne sait pas quel est ce besoin, mais laisse à penser qu'on est sur du microsoft windows. Qui reste, après tout, l'os le plus utilisé, à fortiori pour débuter.

[pyros]

Et, si je parle ici d'un cas particulier, il faut te dire que, de manière tout à fait générale, le principe reste le même pour tout

Pour des technos robustes et fiable comme le C++, la stl, boost etc... la portabilité ne pose en général pas de problèmes (et encore, Solaris possède une implémentation de la stl un peu particulière d'après ce que j'ai pu voir...).

Malheureusement, ce n'est pas toujours le cas. Les developpeurs web me comprendront. Bien que cela se soit grandement ammélioré, du temps d'IE6 (qui représente encore 20% des navigateurs, rapelons-le !), faire un site 100% w3c était le meilleurs moyen d'avoir un site inutilisable pour la pluspart des utilisateurs.
On trouve aussi pas mal de problèmes en programmation graphique. Même en respectant à la lettre la norme OpenGL, il y a toujours des cartes ou des drivers qui posent problème.

Donc dans la mesure du possible il est toujours mieux de faire un code portable, surtout dans des situations aussi simple que faire un syteme("pause"). Mais d'une part il faut garder a l'esprit que dans la pratique "portable" ne signifie pas toujours "porté" ; cela signifie juste que c'est censé marcher sans modifications profonde du code. D'autre part comme l'a dit Bousk, l'essentiel est de correspondre à un besoin. Et parfois, le besoin est de faire un proto rapide, codé en dure, qui ne tournera qu'une seul fois pendant 10min max sur une machine de demo, et qui sera balancé après (c'est du vécu )

Pour ce qui est de la mort de windows 7 dans 3 ans, je prends les paris

[koala01]

Bonjour,

pour rester dans le lynchage, je propose tout de même l'option -w sur visual (propriétés du projet>debugging>command arguments)

Blague à part, la portabilité c'est bien, mais l'essentiel reste de correspondre à son besoin. Dans ce cas on ne sait pas quel est ce besoin, mais laisse à penser qu'on est sur du microsoft windows. Qui reste, après tout, l'os le plus utilisé, à fortiori pour débuter.

En europe, oui, mais ce n'est pas le cas partout...

Et je te rappelle qu'avec des si ...

Plus sérieusement : nous sommes malgré tout ici sur un forum dédiés au professionnels de l'informatique, et nous nous attachons donc à donner des solutions professionnelles.

Cela signifie que, entre une solution qui fonctionne "uniquement si" et qui présente un certain nombre d'inconvénients d'un coté et une solution qui fonctionne quelles que soient les circonstances de l'autre, le choix me semble vite fait, non

j'ai clairement expliqué les problèmes auxquels on risque d'être confronté en décidant d'utiliser l'instruction system, et je rappelle qu'il ne faut jamais préjuger de rien.

Si, malgré ces restrictions, tu décides d'utiliser system("pause") dans un de tes programmes, je ne pourrai pas t'en empêcher, tu sauras à quoi t'en tenir

Mais, de grâce, veilles, lorsque tu réponds sur ce forum, à respecter un minimum ce que l'on considère comme étant les bonnes pratiques de programmation globalement acceptées par l'ensemble des intervenants sur ce forum.

Le débat peut toujours se faire, mais je ne crois vraiment pas qu'il soit opportun qu'il se fasse dans cette discussion

[Bousk]

Je suis on ne peut plus d'accord avec toi
Il n'y a même pas lieu de débat, il y a plusieurs solutions, certaines "mieux" que d'autres, plus rapides à écrire, ou n'importe quelle autre raison qui fera préférer l'une à l'autre dans un cas, mais une autre dans un autre cas.
J'étais juste "amusé" de voir autant de réactions sur un sujet à priori simplissime, alors j'ai ajouté une proposition (qui pourrait être limite qualifiée de trollesque je trouve après coup - mais reste une solution possible ).

Pour ma part, je développe sur visual, donc sur windows. Auparavant sur c::b ou devcpp, j'utilisais system("pause"), puis j'ai vu des codes comme ceux de la faq, que j'ai utilisé pour un autre projet en commun avec un binome qui bossait sous linux et parce que le projet devait tourner sous linux; désormais j'utilise plutôt le -w pour sa simplicité de mon point de vue;
Mais encore une fois, il n'a y a pas, à mon sens, de meilleure réponse. Juste des adaptations au besoin.

edit: en plus je viens de m'apercevoir que -w attend un appui sur "entrée" et pas autre chose

[JolyLoic]

Honnêtement, faire qu'un programme attende une entrée utilisateur une fois qu'il a fini de s'exécuter me semble une mauvaise idée. Que se passera-t-il quand il sera utilisé en ligne de commande ? A l'intérieur d'un script ?

La problème de la fenêtre qui se ferme est un problème de l'environnement de développement, pas un problème du programme. Par exemple, avec visual studio, si on lance le programme par F5 (disposition des touches C++ par défaut), la fenêtre se ferme. Si on le lance par Ctrl-F5, elle reste ouverte à la fin...

[fanjoe31]

merci de toutes vos réponses

désolé d avoir poser encore la question ( je n'avais pas regardé dans le FAQ)