Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ Je reconnais que c'est hors sujet et je m'en excuse ;-)

Je reconnais que c'est hors sujet et je m'en excuse ;-)

18 réponses
Avatar
Lahsen
Salut,


j'exécute un programme simple:


...

int main()
{
cout << " Bonjour..." << "\n";

// ici, il me manque quelque chose pour garder la console à //
l'écran?

return 0;
}

Le problème c'est que la console s'affiche et disparaît aussitôt!!!?

J'ai vu que dans Dev-cpp il y'a:
sytem("Pause")
qui permet de garder la console à l'écran.

est ce qu'il y'a un équivalent pour visual c++?
J'ai cherché dans la msdn et sur le site de microsoft mais je n'ai rien
trouvé.

Merci pour vôtre aide.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Fabien LE LEZ
On Wed, 25 Jul 2007 00:03:40 +0200, Lahsen :

J'ai vu que dans Dev-cpp il y'a:
sytem("Pause")


Non, il n'y a pas. C'est sans conteste la manière la plus crade de
faire ça.

La manière portable de faire les choses est :

void AttenteAppuiEntree()
{
using namespace std;
cout << "Tapez Entree" << endl;
string ligne;
getline (cin, ligne);
}

Avatar
Fabien LE LEZ
On Wed, 25 Jul 2007 00:03:40 +0200, Lahsen :

Je reconnais que c'est hors sujet et je m'en excuse


Au fait, la manière spécifique à un compilateur donné pour attendre
après exécution, c'est tout simplement de demander à l'IDE d'attendre
après l'exécution du programme. Cf la doc de l'IDE en question pour
savoir comment faire.

Avatar
Lahsen
On Wed, 25 Jul 2007 00:03:40 +0200, Lahsen :

Je reconnais que c'est hors sujet et je m'en excuse


Au fait, la manière spécifique à un compilateur donné pour attendre
après exécution, c'est tout simplement de demander à l'IDE d'attendre
après l'exécution du programme. Cf la doc de l'IDE en question pour
savoir comment faire.

Merci,

c'est aussi: system("Pause");


Avatar
Fabien LE LEZ
On Wed, 25 Jul 2007 01:15:02 +0200, Lahsen :

c'est aussi: system("Pause");


Et c'est tout aussi déconseillé sous VC++ que sous g++.
Dans le même style, tu peux écrire

int main()
{
asm
{
// Ici, tout ton programme en assembleur.
}
}

Avatar
Michael DOUBEZ
On Wed, 25 Jul 2007 00:03:40 +0200, Lahsen :

Je reconnais que c'est hors sujet et je m'en excuse


Au fait, la manière spécifique à un compilateur donné pour attendre
après exécution, c'est tout simplement de demander à l'IDE d'attendre
après l'exécution du programme. Cf la doc de l'IDE en question pour
savoir comment faire.

Merci,

c'est aussi: system("Pause");


Tant qu'a utiliser un mecanisme specifique au terminal Windows, tu peux
aussi utiliser getch() qui attends que l'utilisateur tappe une touche.

Michael



Avatar
James Kanze
On Jul 25, 12:08 am, Fabien LE LEZ wrote:
On Wed, 25 Jul 2007 00:03:40 +0200, Lahsen :

Je reconnais que c'est hors sujet et je m'en excuse


Au fait, la manière spécifique à un compilateur donné pour attend re
après exécution, c'est tout simplement de demander à l'IDE d'attend re
après l'exécution du programme. Cf la doc de l'IDE en question pour
savoir comment faire.


Si c'est l'IDE qui démarre son programme, il ne doit pas y avoir
de problème, parce qu'il exécute sous l'IDE, dans un
environement définit par l'IDE. L'IDE capture les sorties
standard, et les affiche dans une fenêtre de l'IDE dédiée à ça.
Sinon, on ne peut guère parler d'IDE, non ? L'exécution du
programme fait bien partie du développement, et donc, est
integré. Je me suis pas servi des IDE récents sous Windows, mais
les IDE sous Unix, et les anciens IDE sous MS-DOS et des
premiers Windows, le faisaient tous. Y aurait-il regression dans
les IDE de Windows ?

Sinon, évidemment, sous Windows, la solution est simple. Tu
ouvres une fenêtre de saisi de commandes, et tu lances le
programme d'elle. Sous Windows, un simple coup de ALT-TAB, et on
est dans la fenêtre qu'on veut. (Sous KDE aussi, mais ce n'est
pas universel sous Unix.)

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


Avatar
James Kanze
On Jul 25, 1:15 am, Lahsen wrote:
Fabien LE LEZ a écrit :> On Wed, 25 Jul 2007 00:03:40 +0200, Lahsen <la :

Je reconnais que c'est hors sujet et je m'en excuse


Au fait, la manière spécifique à un compilateur donné pour atte ndre
après exécution, c'est tout simplement de demander à l'IDE d'atte ndre
après l'exécution du programme. Cf la doc de l'IDE en question pour
savoir comment faire.


Merci,
c'est aussi: system("Pause");


Il démande quand même pas à ce que tu modifies ton code afin de
le tester, non ?

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34



Avatar
Sylvain
Fabien LE LEZ wrote on 25/07/2007 00:08:
On Wed, 25 Jul 2007 00:03:40 +0200, Lahsen :

Je reconnais que c'est hors sujet et je m'en excuse


Au fait, la manière spécifique à un compilateur donné pour attendre
après exécution, c'est tout simplement de demander à l'IDE d'attendre
après l'exécution du programme. Cf la doc de l'IDE en question pour
savoir comment faire.


c'est inexact ici, si maintenant ""IDE"" signifiait script shell
suffisament complexe pour réaliser cela, peut être.

Sylvain.


Avatar
Sylvain
James Kanze wrote on 25/07/2007 11:18:

Si c'est l'IDE qui démarre son programme, il ne doit pas y avoir
de problème, parce qu'il exécute sous l'IDE, dans un
environement définit par l'IDE. L'IDE capture les sorties
standard, et les affiche dans une fenêtre de l'IDE dédiée à ça.


non, pas pour Studio sous Windows en tout cas.

plus que l'environ.t de dév. j'aurais dis que c'est le CRT utilisé qui
peut conditionner la façon dont un programme se lance et s'arrête.

sous Windows, en mode console, le programme est lancé dans un ""shell""
totalement (heureusement) distinct de l'IDE.

Sinon, on ne peut guère parler d'IDE, non ? L'exécution du
programme fait bien partie du développement, et donc, est
integré.


hmm, l'exécution est sous contrôle de l'IDE, il ne fait pas parti de
celui-ci, et j'ai di heureusement car on désire bien que ce prog.
fonctionne à l'identique dans un shell normal et non seulement dans un
shell pipé, redirigé, contrôlé par l'IDE.

les CRT MS mode console n'incluent aucun "pause" en fin d'exécution donc
la fenêtre shell (inhérente au CRT, non à l'iDE) est fermée dès la fin
du main ... et ma manière préférée pour garder ce shell est simplement
de mettre un point d'arrêt à la fin de ce main, faut-il rappeller qu'un
debugger est imho le meilleur outil de mise au point.

Y aurait-il regression dans les IDE de Windows ?


je ne parlerais pas de régression mais de mode de fonctionnement.
et pour de trop récents clicodromes de développement qui redirigeraient
abusivement toutes les IO, je parlerais d'obfuscation nuisible.

Sylvain.

Avatar
James Kanze
On Jul 25, 10:24 pm, Sylvain wrote:
James Kanze wrote on 25/07/2007 11:18:
Si c'est l'IDE qui démarre son programme, il ne doit pas y avoir
de problème, parce qu'il exécute sous l'IDE, dans un
environement définit par l'IDE. L'IDE capture les sorties
standard, et les affiche dans une fenêtre de l'IDE dédiée à ç a.


non, pas pour Studio sous Windows en tout cas.


Ce n'est donc pas un environement integré, puisque pouvoir faire
exécuter le programme sous un environement contrôlé me semble
une fonctionalité fondamentale du développement:-). Ou peut-être
ils trouvaient simplement que de changer vers une fenêtre
« commande prompte » (drôle de nom), et d'exécuter le
programme là, était tellement simple sous Windows qu'on n'avait
pas besoin d'offrir plus. J'ai mes doutes là dessus, mais
peut-être c'est simplement parce que j'ai tellement d'habitude
1) de l'environement Unix, et 2) du développement des programmes
qui n'ont pas de GUI ni ne tourne dans une fenêtre terminale.
(Sous Unix, typiquement, de tels programmes modifient leur
environement de façon à se déconnecter d'un « terminal », si
jamais ils en ont un associé. Ce qui fait que simplement les
lancer dans une fenêtre terminal n'est pas toujours suffisant.)

plus que l'environ.t de dév. j'aurais dis que c'est le CRT utilisé qui
peut conditionner la façon dont un programme se lance et s'arrête.


Je ne comprends pas trop. J'aurais pensé que quand on parle du
lancement, on parle de ce qui se fait avant que le programme se
démarre. Donc, de quelque chose qui est indépendant du CRT.

Suite à des discussions dans comp.lang.c++, Alf Steinbach m'a
renvoyé à un papier excellent
(http://home.no.net/dubjai/win32apitut/01.pdf) qu'il a écrit.
D'après ce que j'ai bien compris de ce papier, l'éditeur de lien
ajoute un attribute (appelée « subsystem ») au fichier .exe,
que le système utilise pour faire certains choix :
l'interprêteur de commande attend la fin du programme ou non, le
component qui lance les programmes quand on clique sur un icon
créer les fait démarrage dans une fenêtre terminal ou non, etc.
(C'est une autre philosophie que Unix, où c'est à l'utilisateur
de préciser chaque fois.) A priori, je supposerais que cette
attribute serait disponible à n'importe quel logiciel qui
voulait lancer un programme. Donc, à IDE, qui pourrait alors
prend ces avants, pour que l'information ne se perd jamais.
(Mais pourquoi, au fond. Il m'arrive d'ajouter des sorties vers
cerr dans mes serveurs. Dans l'opération normale, elles
finissent à /dev/null, mais si je lance le programme depuis une
fenêtre terminal, comme par exemple lors de la mise au point,
elles y apparaissent, et me sont bien utile. De même que dans
l'IDE, elles apparaissent dans la fenêtre que l'IDE a prévu pour
ça.)

sous Windows, en mode console, le programme est lancé dans un
""shell"" totalement (heureusement) distinct de l'IDE.


Le problème n'est pas où le programme est lancé. Le problème,
c'est d'une part, l'environement qu'on lui fournit, et de
l'autre, où arrive cout et cerr. Le programme même, ne sait pas
qui l'a lancé (et il se peut bien que l'IDE Sun se sert d'un
shell pour le lancer).

Sinon, on ne peut guère parler d'IDE, non ? L'exécution du
programme fait bien partie du développement, et donc, est
integré.


hmm, l'exécution est sous contrôle de l'IDE, il ne fait pas parti de
celui-ci, et j'ai di heureusement car on désire bien que ce prog.
fonctionne à l'identique dans un shell normal et non seulement dans un
shell pipé, redirigé, contrôlé par l'IDE.


Quelle est la différence ? Le shell n'est qu'un programme, qui
tourne dans une fenêtre (un xterm, sur mes Unix). Que les
fonctionnalités du terminal soient fournies par le programme
xterm, ou par le programme sun-studio, que le programme soit
lancé par un programme qui s'appelle bash ou ksh, ou qui
s'appelle sun-studio, qu'est-ce que ça change pour le
programme ? Est-ce que tu as peur que l'IDE modifie
l'environement ? C'est toujours possible, mais beaucoup de
l'environement est hérité ; il sera différent, que l'IDE lance
le programme dans un fenêtre terminal à part, ou dans sa propre
fenêtre terminal.

les CRT MS mode console n'incluent aucun "pause" en fin d'exécution donc
la fenêtre shell (inhérente au CRT, non à l'iDE) est fermée dès la fin
du main ...


Qui a ouvert la fenêtre ? Pas le CRT, je crois. Et qui le
ferme ? Pas le CRT non plus ; elle ne se ferme pas si je lance
le programme à la main dans une fenêtre terminal.

et ma manière préférée pour garder ce shell est simplement
de mettre un point d'arrêt à la fin de ce main, faut-il rappeller qu' un
debugger est imho le meilleur outil de mise au point.


J'avoue que je ne me sert du debuggueur pratiquement que pour
les post mortem. Mais je ne vois pas l'intérêt de ne pas avoir
une fenêtre ou une sous-fenêtre avec les sorties standard.
Évidemment, avant de livrer le code, je l'aurais testé aussi
dans son environement réel (où, dans mon cas, les sorties
standard sont dirigées vers /dev/null. Un trou noir, en quelque
sort). Mais pendant la mise au point, ce n'est pas forcement
genant d'avoir des sorties en plus.

Y aurait-il regression dans les IDE de Windows ?


je ne parlerais pas de régression mais de mode de fonctionnement.
et pour de trop récents clicodromes de développement qui redirigeraie nt
abusivement toutes les IO, je parlerais d'obfuscation nuisible.


Qui redirigeraient quoi ? Les sorties standard doivent toujours
aboutir quelque part.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


1 2