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++ Création fichier de config ...

Création fichier de config ...

63 réponses
Avatar
Manu
Je suis on ne peut plus débutant en c/c++ , et je suis confronté à un
problème que je n'arrive pas à résoudre.
J'ai crée un petit client irc de base dans le but d'en faire une espèce de
robot à tout faire que j'améliorerai en fonction de mes idées du moment ...

ceci dit , 2 questions :

1) comment faire de mon programme un exe tournant en "toile de fond" ( cad
pas etre obligé de conserver la fenetre de ligne de cmd sous XP pour que le
prog tourne ) ?

2) apres un premier lancement , je voudrai crée un fichier de config
regroupant les infos principales ( server , channel , nickname .. )
permettant ensuite de relancer le client a partir de ce fichier sans avoir a
indiquer les arg en ligne de commande

void config_pass(int i , char* data)
{
FILE* Config;
Config = fopen("iBot.txt","w");
if (i == 1) { printf("Server : "); fputs(data, Config); fputs("\n",
Config); }
if (i == 2) { printf("Port : "); fputs(data, Config); }
if (i == 3) { printf("Channel : "); /* printf(data, Config); printf("\n",
Config); */ }
( ... )
}

bon je me doute que ca doit être un peu fouilli et pas du tout optimisé ...
i correspond en gros au nombre d'arguments en ligne de commande

en fait , je cherche un moyen de faire le fichier iBot.txt de facon
convenable , parce que avec tous mes essais ( essais avec fputs / fwrite /
... enfin un peu tout ) , le data correspondant a la chaine de caractères de
chaque arg s'ecrit bien dans le fichier .txt , mais uniquement sur la
premiere ligne , et ce en effacant bien entendu ce qui avait été ecrit
précédemment

exemple : server irc.epiknet.org
port : 6667
->> donne en premiere ligne : 6667epiknet.org au deuxieme tour

donc en gros , j'aimerai savoir comment faire sauter une ligne pour avoir
chaque ch de caractères de chaque arg sur une ligne différente :)

bon je sais c c confus ... pardonnez mon langage de débutant , j'ai voulu
etre le plus clair possible

merci de votre aide et bon week end !
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
3 4 5 6 7
Avatar
kanze
Fabien LE LEZ wrote in message
news:...
On 05 Oct 2003 17:17:44 +0200, James Kanze
wrote:

Tu pourrais lui expliquer pourquoi.


Certes, je pourrais effectivement recopier la FAQ ici.


Il parlait de lancer un processus en toile de fond. Autant que je sache,
la FAQ n'en parle pas.

Il aurait fallu quand même que tu lui dises que le langage C++ ne
connaît pas cette idée, qu'il n'y a donc pas de solution portable.

La norme C++ définit bien fopen, printf, etc. Elles font bien partie
de C++. Mais pour des raisons de compatibilité C, surtout. C'est du
C++, mais ce n'est pas comme ça qu'écrirait un bon programmeur C++.


Justement. A priori, les lecteurs de fclc++ ne connaissent pas
grand-chose à printf et compagnie (sauf s'ils ont fait du C avant),


Ou qu'ils ont à maintenir du code des autres. Il existe un certain
nombre de programmeurs C++ qui réfusent les flux, et qui continuent avec
les printf.

Ou qu'ils ont à écrire du code qui supporte des messages dans des
langues différentes, sur des systèmes Unix. Sous Unix, printf supporte
des paramètres positionnels.

Ou qu'ils ont essayé à comprendre les flux en lisant la norme. La
sémantiques des flux est documentées dans la norme en termes des
formattages printf.

Ou qu'ils se sont servi de boost::format ou de GB_Format : des classes
C++ qui supportent un formattage à la printf.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16


Avatar
Gabriel Dos Reis
writes:

| Fabien LE LEZ wrote in message
| news:...
| > On 05 Oct 2003 17:17:44 +0200, James Kanze
| > wrote:
|
| > >Tu pourrais lui expliquer pourquoi.
|
| > Certes, je pourrais effectivement recopier la FAQ ici.
|
| Il parlait de lancer un processus en toile de fond. Autant que je sache,
| la FAQ n'en parle pas.

elle pourrait en parler, si cela devenait un besoin.

-- Gaby
Avatar
Gabriel Dos Reis
writes:

| Gabriel Dos Reis wrote in message
| news:...
| > James Kanze writes:
|
| > [...]
|
| > | |> int *p = make_point(467, 39).coord; // #2
|
| > | C'est effectivement une subtilité. Où d'ailleurs les compilateurs ne
| > | sont pas tous d'accord.
|
| > C'est une erreur en C90, et c'est bien formé en C99, mais avec
| > d'autres subtilités en plus.
|
| C-à-d. La seule subtilité que je vois, c'est qu'on prend l'adresse d'un
| non-lvalue.

Où vois-tu que cette expression prend l'adresse d'une lvalue ?

| Le problème, si mes souvenirs sont corrects (ce qui est loins d'être
| certain), c'était qu'une expression du type :
|
| int i = make_point( 1, 2 ).coord[ 0 ] ;
|
| n'était pas légal avant (C90, K&R), parce que la définition formelle de
| [] dépend de la conversion implicite en pointeur, et que cette
| conversion ne se faisait que sur des lvalue.

Mais, mais ce n'est pas l'expression dont il est question.

| Et c'est vrai qu'en permettant ce genre d'expression, C a introduit le
| problème de la durée de vie des temporaires qu'on connaît si bien en
| C++.

et bien défini. En fait, C99 a transformé les programmes explicitement
marqués invalides (en C90) en programmes ayant des fonctionnements
indéfinis. En général, c'est dans l'autre sens qu'on souhaite aller.

| > | |> Est-ce que #2 est bien formé ?
|
| > | Il me semble qu'il y a eu une TC à ce sujet, mais je ne me rappelle
| > | pas la réponse. (A priori, j'aurais dis non, parce que prendre
| > | l'adresse suppose un lvalue, et la valeur de retour d'une fonction
| > | n'est pas un lvalue.)
|
| > En C90, c'est formellement invalide et un diagnostic est requis. Par
| > contre c'est bien formé en C99.
|
| > | Mais je crois que C++ a le même problème. C'est donc qu'il n'y a pas
| > | de différence à cet égard.
|
| > Non, C++ n'a pas cette « subtilité. »
|
| Est-ce que tu pourrais m'indiquais où il l'a éliminé ? J'ai jeté un coup
| d'oeil rapide, et je n'ai pas vu de différence entre C(99) et C++ quand
| il s'agit d'une variable membre non-statique.

De quelle limitation ?

-- Gaby
Avatar
Manu
faudrait donc démander dans un groupe spécialisé Windows.


On m' a dèjà fait part du groupe adéquat ... j'y passerai en temps voulu
quand j'aurai régler tous les autres aspects de mon code.
Chaque chose en son temps :)

Si tu ouvres le fichier en écriture, et tu le
laisses ouvert jusqu'à ce que tu as tout écrit, tu ne dois pas
avoir ce problème.


En fait je suis parvenu a obtenir ce que je voulais avec un
fopen("fichier.txt", "a"); et non pas "w".
Les autres instructions marchaient parfaitement et j'obtiens donc à présent
le fichier tant voulu. D'une façon peut être pas très orthodoxe , mais je ne
suis ni puriste ni programmeur.

Quant à votre code , je vous en remercie bien ; même si je ne vais pas
l'utiliser pour le moment je le mets sous le coude pour une prochaine
version ou encore pour créer à partir de l'étude de ces quelques lignes une
fonction permettant de faire un read ligne par ligne de ce fichier .txt en
vue de lancer l'exe a partir de son fichier de config et sans avoir a
utiliser d'arguments.

Avec mes remerciements , à faire parvenir également aux 2 ou 3 personnes qui
ont su me donner des réponses constructives.

Avatar
kanze
Gabriel Dos Reis wrote in message
news:...
writes:

| Gabriel Dos Reis wrote in message
| news:...
| > James Kanze writes:

| > [...]

| > | |> int *p = make_point(467, 39).coord; // #2

| > | C'est effectivement une subtilité. Où d'ailleurs les
| > | compilateurs ne sont pas tous d'accord.

| > C'est une erreur en C90, et c'est bien formé en C99, mais avec
| > d'autres subtilités en plus.

| C-à-d. La seule subtilité que je vois, c'est qu'on prend l'adresse
| d'un non-lvalue.

Où vois-tu que cette expression prend l'adresse d'une lvalue ?


Elle prend l'adresse d'une non-lvalue, comme j'ai dit. (Vue qu'on parle
de C, j'utilise le vocabulaire de C.)

| Le problème, si mes souvenirs sont corrects (ce qui est loins d'être
| certain), c'était qu'une expression du type :

| int i = make_point( 1, 2 ).coord[ 0 ] ;

| n'était pas légal avant (C90, K&R), parce que la définition formelle
| de [] dépend de la conversion implicite en pointeur, et que cette
| conversion ne se faisait que sur des lvalue.

Mais, mais ce n'est pas l'expression dont il est question.


Peut-être. Mais c'est bien l'expression qui a motivé le changement entre
C90 et C99.

| Et c'est vrai qu'en permettant ce genre d'expression, C a introduit
| le problème de la durée de vie des temporaires qu'on connaît si bien
| en C++.

et bien défini.


La durée de vie d'un temporaire n'est bien définie en C++ que depuis
bien peu de temps (enfin, pour une assez grande valeur de peu, quand
même), et il s'avère que même aujourd'hui, il y a des compilateurs qui
ne l'implémentent pas. Du coup, de point de vue pratique, elle n'est pas
encore bien définie, et elle pose des problèmes pour celui qui veut
écrire du code portable.

En fait, C99 a transformé les programmes explicitement marqués
invalides (en C90) en programmes ayant des fonctionnements
indéfinis. En général, c'est dans l'autre sens qu'on souhaite aller.


Je suis d'accord. Je ne faisais qu'exposer la motivation de ce
changement. Je ne dis pas que je suis d'accord. (Vue la quantité de C
que je fais, je dirais même que je m'en fous. Mais on pourrait aussi
dire que vue la quantité de comportements indéfinis en C, on n'est pas à
ça près.)

| > | |> Est-ce que #2 est bien formé ?

| > | Il me semble qu'il y a eu une TC à ce sujet, mais je ne me
| > | rappelle pas la réponse. (A priori, j'aurais dis non, parce que
| > | prendre l'adresse suppose un lvalue, et la valeur de retour
| > | d'une fonction n'est pas un lvalue.)

| > En C90, c'est formellement invalide et un diagnostic est
| > requis. Par contre c'est bien formé en C99.

| > | Mais je crois que C++ a le même problème. C'est donc qu'il n'y a
| > | pas de différence à cet égard.

| > Non, C++ n'a pas cette « subtilité. »

| Est-ce que tu pourrais m'indiquais où il l'a éliminé ? J'ai jeté un
| coup d'oeil rapide, et je n'ai pas vu de différence entre C(99) et
| C++ quand il s'agit d'une variable membre non-statique.

De quelle limitation ?


Qu'il y a un comportement défini ici en C++. Parque pour l'instant, je
ne vois aucune différence entre la règle C99 et la règle C++.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Avatar
kanze
Gabriel Dos Reis wrote in message
news:...
writes:
| Fabien LE LEZ wrote in message
| news:...
| > On 05 Oct 2003 17:17:44 +0200, James Kanze
| > wrote:

| > >Tu pourrais lui expliquer pourquoi.

| > Certes, je pourrais effectivement recopier la FAQ ici.

| Il parlait de lancer un processus en toile de fond. Autant que je
| sache, la FAQ n'en parle pas.

elle pourrait en parler, si cela devenait un besoin.


Si tu veux qu'elle en parle de tout ce qui ne fait pas partie du
langage C++, on n'est pas sorti de l'auberge.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Avatar
Gabriel Dos Reis
writes:

| Gabriel Dos Reis wrote in message
| news:...
| > writes:
| > | Fabien LE LEZ wrote in message
| > | news:...
| > | > On 05 Oct 2003 17:17:44 +0200, James Kanze
| > | > wrote:
|
| > | > >Tu pourrais lui expliquer pourquoi.
|
| > | > Certes, je pourrais effectivement recopier la FAQ ici.
|
| > | Il parlait de lancer un processus en toile de fond. Autant que je
| > | sache, la FAQ n'en parle pas.
|
| > elle pourrait en parler, si cela devenait un besoin.
|
| Si tu veux qu'elle en parle de tout ce qui ne fait pas partie du
| langage C++, on n'est pas sorti de l'auberge.

« si cela devenait un besoin » n'est pas « si je veux qu'elle parle »

ce qui concerne l'aubrege, on est plutôt dehors.

-- Gaby
Avatar
Gabriel Dos Reis
writes:

| Gabriel Dos Reis wrote in message
| news:...
| > writes:
|
| > | Gabriel Dos Reis wrote in message
| > | news:...
| > | > James Kanze writes:
|
| > | > [...]
|
| > | > | |> int *p = make_point(467, 39).coord; // #2
|
| > | > | C'est effectivement une subtilité. Où d'ailleurs les
| > | > | compilateurs ne sont pas tous d'accord.
|
| > | > C'est une erreur en C90, et c'est bien formé en C99, mais avec
| > | > d'autres subtilités en plus.
|
| > | C-à-d. La seule subtilité que je vois, c'est qu'on prend l'adresse
| > | d'un non-lvalue.
|
| > Où vois-tu que cette expression prend l'adresse d'une lvalue ?
^

| Elle prend l'adresse d'une non-lvalue, comme j'ai dit. (Vue qu'on parle
| de C, j'utilise le vocabulaire de C.)

ma question devait plutôt s'écrire : où est-ce que tu vois qu'elle
prend l'adresse d'une non-lvalue ?


|
| > | Le problème, si mes souvenirs sont corrects (ce qui est loins d'être
| > | certain), c'était qu'une expression du type :
|
| > | int i = make_point( 1, 2 ).coord[ 0 ] ;
|
| > | n'était pas légal avant (C90, K&R), parce que la définition formelle
| > | de [] dépend de la conversion implicite en pointeur, et que cette
| > | conversion ne se faisait que sur des lvalue.
|
| > Mais, mais ce n'est pas l'expression dont il est question.
|
| Peut-être. Mais c'est bien l'expression qui a motivé le changement entre
| C90 et C99.

Dans cette discussion, il est question d'une expression donnée, pas
celle que quelqu'un pense aurait motivé quelque chose.

| > | Et c'est vrai qu'en permettant ce genre d'expression, C a introduit
| > | le problème de la durée de vie des temporaires qu'on connaît si bien
| > | en C++.
|
| > et bien défini.
|
| La durée de vie d'un temporaire n'est bien définie en C++ que depuis
| bien peu de temps (enfin, pour une assez grande valeur de peu, quand
| même),

l'essentiel est qu'elle soit bien définie.

| et il s'avère que même aujourd'hui, il y a des compilateurs qui
| ne l'implémentent pas. Du coup, de point de vue pratique, elle n'est pas
| encore bien définie, et elle pose des problèmes pour celui qui veut
| écrire du code portable.

je ne sais pas si cela t'a échappé, mais il s'agit du langage et non
de savoir programmer correctement ou de manière portable.

[...]

| > | > | |> Est-ce que #2 est bien formé ?
|
| > | > | Il me semble qu'il y a eu une TC à ce sujet, mais je ne me
| > | > | rappelle pas la réponse. (A priori, j'aurais dis non, parce que
| > | > | prendre l'adresse suppose un lvalue, et la valeur de retour
| > | > | d'une fonction n'est pas un lvalue.)
|
| > | > En C90, c'est formellement invalide et un diagnostic est
| > | > requis. Par contre c'est bien formé en C99.
|
| > | > | Mais je crois que C++ a le même problème. C'est donc qu'il n'y a
| > | > | pas de différence à cet égard.
|
| > | > Non, C++ n'a pas cette « subtilité. »
|
| > | Est-ce que tu pourrais m'indiquais où il l'a éliminé ? J'ai jeté un
| > | coup d'oeil rapide, et je n'ai pas vu de différence entre C(99) et
| > | C++ quand il s'agit d'une variable membre non-statique.
|
| > De quelle limitation ?
|
| Qu'il y a un comportement défini ici en C++.

mais ça, tout le monde le sait. La question portait sur C.

| Parque pour l'instant, je
| ne vois aucune différence entre la règle C99 et la règle C++.

(1) est-ce que make_point(467, 39).coord est un objet ?
(2) est-ce que le pointeur obtenu par conversion de
make_point(467, 39).coord pointe sur un objet ?

-- Gaby
Avatar
kanze
Gabriel Dos Reis wrote in message
news:...
writes:

| Gabriel Dos Reis wrote in message
| news:...
| > writes:

| > | Gabriel Dos Reis wrote in message
| > | news:...
| > | > James Kanze writes:

| > | > [...]

| > | > | |> int *p = make_point(467, 39).coord; // #2

| > | > | C'est effectivement une subtilité. Où d'ailleurs les
| > | > | compilateurs ne sont pas tous d'accord.

| > | > C'est une erreur en C90, et c'est bien formé en C99, mais avec
| > | > d'autres subtilités en plus.

| > | C-à-d. La seule subtilité que je vois, c'est qu'on prend
| > | l'adresse d'un non-lvalue.

| > Où vois-tu que cette expression prend l'adresse d'une lvalue ?
^

| Elle prend l'adresse d'une non-lvalue, comme j'ai dit. (Vue qu'on
| parle de C, j'utilise le vocabulaire de C.)

ma question devait plutôt s'écrire : où est-ce que tu vois qu'elle
prend l'adresse d'une non-lvalue ?


Le type de l'expression d'initialisation est bien int[2]. Et elle n'est
pas un lvalue. Il y a donc une conversion implicite de int[] en int*,
qui prend en fait l'adresse du premier élément.

| > | Le problème, si mes souvenirs sont corrects (ce qui est loins
| > | d'être certain), c'était qu'une expression du type :

| > | int i = make_point( 1, 2 ).coord[ 0 ] ;

| > | n'était pas légal avant (C90, K&R), parce que la définition
| > | formelle de [] dépend de la conversion implicite en pointeur, et
| > | que cette conversion ne se faisait que sur des lvalue.

| > Mais, mais ce n'est pas l'expression dont il est question.

| Peut-être. Mais c'est bien l'expression qui a motivé le changement
| entre C90 et C99.

Dans cette discussion, il est question d'une expression donnée, pas
celle que quelqu'un pense aurait motivé quelque chose.


Les motivations aident à la compréhension. (Évidement, il y en a qui ne
veulent pas comprendre. Pour eux, la motivation est certes sans
intérêt.)

| > | Et c'est vrai qu'en permettant ce genre d'expression, C a
| > | introduit le problème de la durée de vie des temporaires qu'on
| > | connaît si bien en C++.

| > et bien défini.

| La durée de vie d'un temporaire n'est bien définie en C++ que depuis
| bien peu de temps (enfin, pour une assez grande valeur de peu, quand
| même),

l'essentiel est qu'elle soit bien définie.


Aujourd'hui, à condition d'avoir un compilateur conforme à la norme.
Pour moi, elle n'est pas définie, parce qu'elle n'est pas identique avec
de divers compilateurs dont j'ai à faire.

| et il s'avère que même aujourd'hui, il y a des compilateurs qui ne
| l'implémentent pas. Du coup, de point de vue pratique, elle n'est
| pas encore bien définie, et elle pose des problèmes pour celui qui
| veut écrire du code portable.

je ne sais pas si cela t'a échappé, mais il s'agit du langage et non
de savoir programmer correctement ou de manière portable.


À bon. On s'en fout alors de la réalité.

Alors, la discussion devient la masturbation mentale, et cesse de
m'intéresser. Parce que le C++, je le fais pour une raison, et une
raison seulement -- créer des applications qui marchent. (Sinon,
franchement, il y a bien de sujets plus intéressants.)

[...]

| > | > | |> Est-ce que #2 est bien formé ?

| > | > | Il me semble qu'il y a eu une TC à ce sujet, mais je ne me
| > | > | rappelle pas la réponse. (A priori, j'aurais dis non, parce
| > | > | que prendre l'adresse suppose un lvalue, et la valeur de
| > | > | retour d'une fonction n'est pas un lvalue.)

| > | > En C90, c'est formellement invalide et un diagnostic est
| > | > requis. Par contre c'est bien formé en C99.

| > | > | Mais je crois que C++ a le même problème. C'est donc qu'il
| > | > | n'y a pas de différence à cet égard.

| > | > Non, C++ n'a pas cette « subtilité. »

| > | Est-ce que tu pourrais m'indiquais où il l'a éliminé ? J'ai jeté
| > | un coup d'oeil rapide, et je n'ai pas vu de différence entre
| > | C(99) et C++ quand il s'agit d'une variable membre non-statique.

| > De quelle limitation ?

| Qu'il y a un comportement défini ici en C++.

mais ça, tout le monde le sait. La question portait sur C.

| Parque pour l'instant, je ne vois aucune différence entre la règle
| C99 et la règle C++.

(1) est-ce que make_point(467, 39).coord est un objet ?


Oui. Enfin, en C++, je ne suis pas sûr -- il y a des histoires avec des
rvalues qui n'ont pas un type classe. En C, en revanche, du moment que
ça occupe de la mémoire et qu'il a une adresse, c'est un objet.

Le problème, c'est la durée de vie de l'objet.

(2) est-ce que le pointeur obtenu par conversion de
make_point(467, 39).coord pointe sur un objet ?


Certainement. Jusqu'à la fin de la vie de l'objet.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Avatar
kanze
"Manu" wrote in message
news:<blrudl$1r0$...

Si tu ouvres le fichier en écriture, et tu le
laisses ouvert jusqu'à ce que tu as tout écrit, tu ne dois pas
avoir ce problème.


En fait je suis parvenu a obtenir ce que je voulais avec un
fopen("fichier.txt", "a"); et non pas "w".
Les autres instructions marchaient parfaitement et j'obtiens donc à
présent le fichier tant voulu. D'une façon peut être pas très
orthodoxe , mais je ne suis ni puriste ni programmeur.


C'est une autre solution. Elle est beaucoup plus coûteuse en termes de
ressources système que celle que j'ai proposée. Ce qui peut être ou ne
pas être un problème, selon l'utilisation.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16


3 4 5 6 7