Discussion :

[mok16]

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

[Laurent Gomila]

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

[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

[ZaaN]

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

[mok16]

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

le programme se compile et se link et tout est correct

[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

[koala01]

Salut,

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

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

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 :

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

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

[Médinoc]

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.

[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.

[koala01]

...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

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

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

Code :

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

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;
}

[r0d]

Code :

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

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 :

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

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;
}

:]

[koala01]

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

Code :

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

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 :

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

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

[Luc Hermitte]

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

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).

[Médinoc]

Il me semble que c'est l'EDI qui appelle pause, pas le programme lancé : Lui n'attend jamais.

[Luc Hermitte]

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