Mes applications console ne s'éxecutent pas

Version imprimable

09/01/2007, 15h07
mok16

Mes applications console ne s'éxecutent pas

je ne sais pas pourquoi mes petits programme console ne veulent pas s'éxecuter sous C++Builder. Aidez moi SVP
09/01/2007, 15h11
Laurent Gomila

Citation:

je ne sais pas pourquoi mes petits programme console ne veulent pas s'éxecuter sous C++Builder

Moi non plus.

Bon, pour donner quand même une réponse totalement au pif :
http://c.developpez.com/faq/cpp/?pag...e#SL_cin_pause
09/01/2007, 15h30
Thierry Chappuis

Salut,

Peut-être que tu peux en dire plus, car à part y aller au pif comme Laurent, je vois pas trop comment résoudre ton problème.

Thierry
09/01/2007, 15h40
ZaaN

ton programme se compile et se link t'il correctement ?
10/01/2007, 09h38
mok16

Citation:

Envoyé par ZaaN

ton programme se compile et se link t'il correctement ?

le programme se compile et se link et tout est correct
10/01/2007, 11h49
Thierry Chappuis

Par exemple, tu pourrais montrer un exemple de petit programme qui ne s'exécute pas et essayer la solution proposée par Laurent Gomila. Si c'est uniquement un problème d'affichage, essaie de faire créer à ton programme un fichier et d'y écrire des traces tout au long de l'exécution de ce dernier. De cette manière, si le fichier est créé correctement, tu peux vérifier que le programme s'exécute bel et bien et où tu rencontres un problème.

Tu peux également suivre l'exécution de ton programme pas à pas à l'aide du débogueur.

Thierry
10/01/2007, 12h03
koala01
Salut,

D'abord, qu'entend-tu par "mes applications consoles ne semblent pas s'exécuter":question:

Est-ce le fait que, une fois sorti de l'IDE, si tu double clique sur l'application générée, tu as une fenetre noire qui s'ouvre et se referme très rapidement :question:

Si tel est le cas, tu as deux solutions distinctes:
- La première consiste à lancer une console (menu démarrer>tous les programmes>accessoires> invite de commande), à aller dans le dossier dans lequel se trouve ton application et à lancer l'application au départ meme de la ligne de commande, au lieu de double cliquer dessus
- La deuxième, peut etre préférable, consiste à prévoir une pause dans l'exécution de l'application, juste avant le dernier return 0 de la fonction main
En effet, sous windows, si tu ne prévois pas une pause en fin d'exécution (ce pourrait, meme si ce n'est pas portable, se traduire par l'ajout d'un system("PAUSE") avant le return de la fonction main, ou par une série d'autres possilités bien préférables parce que plus portables) une console va s'ouvrir au début de l'exécution... et se refermer dés que l'exécution prend fin (ce qui donne l'impression que ca n'a pas fonctionné)

Par contre, si tu lance l'application directement dans une console, et non en double cliquant dessus, vu que la console existe "indépendemment" de l'application, tu pourra voir les sorties consoles que l'application a provoquées ;)

Enfin, certains EDI "englobent" l'exécution de l'application en cours de création dans, justement, un système qui permet d'attendre que l'utilisateur appuie sur une touche avant de quitter la console, et d'autres non.

Il me *semble* que Borland C++ builder fait partie de la deuxième catégorie...

Le meme problème ayant les mêmes solutions, j'ai déjà indiqué comment le résoudre (system("PAUSE") ou similaire dans le code)

NOTA: la méthode la plus portable pour provoquer une pause peut prendre, tout simplement, la forme d'un
Code:

1 2 std::cout<<std::endl<<"Appuyez sur une touche pour quitter"; std::cin.get();
Si, enfin, tu entends tout autre chose par "mon application ne veut pas s'exécuter", il s'agira d'être plus précis pour que l'on puisse t'aider ;)
11/01/2007, 09h17
Médinoc
Citation:
Envoyé par koala01

Si tel est le cas, tu as deux solutions distinctes:

La première consiste à lancer une console (menu démarrer>tous les programmes>accessoires> invite de commande), à aller dans le dossier dans lequel se trouve ton application et à lancer l'application au départ meme de la ligne de commande, au lieu de double cliquer dessus
La deuxième, peut etre préférable, consiste à prévoir une pause dans l'exécution de l'application, juste avant le dernier return 0 de la fonction main
...et peut-être pas. Le propre d'un "petit" programme console est de ne réclamer aucune entrée, pour pouvoir être utilisé en batch.

Enfin bien sûr, pour un programme de test ou de démonstration, on peut se permettre de rajouter une attente. :)
11/01/2007, 10h21
Luc Hermitte

On peut aussi utiliser un vrai EDI :roll:
NB: certains proposent les deux options -> avec attente pour l'exécution normale, sans attente pour l'exécution au travers du débuggueur.

Citation:

Envoyé par Médinoc

...et peut-être pas. Le propre d'un "petit" programme console est de ne réclamer aucune entrée, pour pouvoir être utilisé en batch.

Enfin bien sûr, pour un programme de test ou de démonstration, on peut se permettre de rajouter une attente. :)

C'était bien la raison du "peut etre"...

Le propre d'un conseil donné est qu'il doit etre pondéré par les impératifs de la situation à laquelle il s'applique ;)

Généralement, quand on prodigue un conseil, on le pondère soi-même en connaissance de cause, mais, n'ayant pas tous les tenants et aboutissants, c'est au demandeur de le faire, et à nous de veiller à ne pas etre trop restrictif... Quitte à ce qu'une proposition particulière ne soit, en définitive, que l'expression d'une exeption ;)

Citation:

Envoyé par Luc Hermitte

On peut aussi utiliser un vrai EDI
NB: certains proposent les deux options -> avec attente pour l'exécution normale, sans attente pour l'exécution au travers du débuggueur.

ne veux tu pas, plutot, dire "avec attente au travers de l'EDI et sans attente pour exécution normale :question:

Autrement, il est aussi possible de prévoir un état "debug" dans le code, grâce, entre autre, aux instruction preprocesseur...
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 #include <iostream> #ifndef DEGUB #define DEBUG 1//passer à 0 pour version finale //peut etre en profiter pour organiser un "affichage sur erreur" ;) #endif int main() { //... if(DEBUG) { std::cout<<"appuiez sur une touche pour quitter"; std::cin.get(); } return 0; }

Citation:

Envoyé par koala01

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
#include <iostream>
 
#ifndef DEGUB
#define DEBUG 1//passer à 0 pour version finale
//peut etre en profiter pour organiser un "affichage sur erreur" ;)
#endif
int main()
{
 //...
    if(DEBUG)
    {
        std::cout<<"appuiez sur une touche pour quitter";
        std::cin.get();
    }
    return 0;
}

Je chipotte certes, mais on peut faire tout simplement:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
 
#include <iostream>
 
int main()
{
 //...
#ifdef DEBUG
    std::cout<<"appuiez sur une touche pour quitter";
    std::cin.get();
#endif
 
    return 0;
}

Aussi, ou prévoir une série de choses dépendantes de DEBUG:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
#include <iostream>
#include <fstream>
 
#ifndef DEBUG
#define DEBUG 1 //passer à 0 pour version finale
#if DEBUG
#define ENDDEBUG std::cout<<"appuyez sur une touche pour quitter";\
                 std::cin.get()
#define PRINT(x) std::cout<<x<<std::endl;
#define LOG(x) std::ofstream ofs("error.log", std::ios_base::app);\
               ofs<<x<<std::endl;
#else //pour le if DEBUG
#define ENDDEBUG
#define PRINT(x)
#define LOG(x)
#endif //pour le if DEBUG
#endif //pour le ifdef

Et ca peut donner des trucs sympa par le simple fait d'un code du genre de

Code:

1
2
3
4
5
6
7
8
9
10
11
 
int main()
{
    //...
    PRINT("affichage uniquement en mode 'debug'");
    LOG("Logging pour tracer l'erreur");
    //attend une touche avant de quitter en mode debug uniquement
    //...
    ENDDEBUG;
    return 0;
}

Finalement, la seule limite est celle de l'imagination du concepteur ;) :P

11/01/2007, 22h54
Luc Hermitte

Citation:

Envoyé par koala01

ne veux tu pas, plutot, dire "avec attente au travers de l'EDI et sans attente pour exécution normale :question:

Non.
Exécution depuis la console => pas d'attente
Exécution normale depuis l'EDI => attente
Exécution via débuggueur de l'EDI => pas d'attente

C'était le comportement par défaut de V6. Et ma foi, il est très bien.
Après, en fonction des bibliothèques linkées (/du type du projet), je ne serai pas surpris que l'on puisse décider de ne jamais attendre (histoire de ne pas avoir à appuyer sur une touche après avoir fermé une fenêtre).
12/01/2007, 16h26
Médinoc

Il me semble que c'est l'EDI qui appelle pause, pas le programme lancé : Lui n'attend jamais.
12/01/2007, 23h54
Luc Hermitte

C'est bien comme ça que ce devrait être -- histoire de ne pas pourrir les codes de system("pause").