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
| Gabriel Dos Reis writes: | | |> Loïc Joly writes: | | |> | que le C++ (dans le sens son étendue est plus limitée, il | |> | est plus facile de le maitriser complètement). | | |> ce point n'est pas évident. | | Je crois qu'il parlait de maîtriser le langage.
Mais c'est bien à cela que j'ai répondu.
C'est fou ça.
-- Gaby
James Kanze <kanze@alex.gabi-soft.fr> writes:
| Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> writes:
|
| |> Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
|
| |> | que le C++ (dans le sens son étendue est plus limitée, il
| |> | est plus facile de le maitriser complètement).
|
| |> ce point n'est pas évident.
|
| Je crois qu'il parlait de maîtriser le langage.
| Gabriel Dos Reis writes: | | |> Loïc Joly writes: | | |> | que le C++ (dans le sens son étendue est plus limitée, il | |> | est plus facile de le maitriser complètement). | | |> ce point n'est pas évident. | | Je crois qu'il parlait de maîtriser le langage.
Mais c'est bien à cela que j'ai répondu.
C'est fou ça.
-- Gaby
Samuel Krempp
le Sunday 05 October 2003 15:18, écrivit :
"_M.B._" a écrit dans le message de news:blp3g5$gqc$
T'as rien de mieux a faire que de venir taper ta frime ici [..]
Mais pourquoi est-il si méchant... ;)
Parce-que !
-- Sam fan club MB - sinon la pulpe, elle reste en bas.
le Sunday 05 October 2003 15:18, christophe-lephay@wanadoo.fr écrivit :
"_M.B._" <_mbinder@magicnet.com> a écrit dans le message de
news:blp3g5$gqc$1@news-reader4.wanadoo.fr...
T'as rien de mieux a faire que de venir taper ta frime ici
[..]
Mais pourquoi est-il si méchant... ;)
Parce-que !
--
Sam
fan club MB - sinon la pulpe, elle reste en bas.
"Samuel Krempp" a écrit dans le message news: 3f80531a$0$2788$
-- Sam fan club MB - sinon la pulpe, elle reste en bas.
:-)
T'as payé ta cotisation ? Bon, c'est gratos pour les 10 premiers.
MB
Fabien LE LEZ
On 05 Oct 2003 17:17:44 +0200, James Kanze wrote:
Tu pourrais lui expliquer pourquoi.
Certes, je pourrais effectivement recopier la FAQ ici.
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), tandis que les lecteurs de fclc seront bien plus à même de le renseigner sur ce genre de méthodes.
On 05 Oct 2003 17:17:44 +0200, James Kanze <kanze@alex.gabi-soft.fr>
wrote:
Tu pourrais lui expliquer pourquoi.
Certes, je pourrais effectivement recopier la FAQ ici.
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),
tandis que les lecteurs de fclc seront bien plus à même de le
renseigner sur ce genre de méthodes.
Certes, je pourrais effectivement recopier la FAQ ici.
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), tandis que les lecteurs de fclc seront bien plus à même de le renseigner sur ce genre de méthodes.
Justement. A priori, les lecteurs de fclc++ ne connaissent pas grand-chose à printf et compagnie (sauf s'ils ont fait du C avant),
printf est un mauvais exemple, en fait la norme décrit le résultat du formattage des nombres en termes de résultat d'un printf avec un format-string adéquat. (ce qui fait que certaines implémentations se contentent de synthétiser un format-string à partir des paramètres du stream et de passer la main à printf). Enfin bref, pour connaitre le formattage des streams C++, il faut connaître celui de printf.
-- Sam
le Sunday 05 October 2003 22:23, gramster@gramster.com écrivit :
Justement. A priori, les lecteurs de fclc++ ne connaissent pas
grand-chose à printf et compagnie (sauf s'ils ont fait du C avant),
printf est un mauvais exemple, en fait la norme décrit le résultat du
formattage des nombres en termes de résultat d'un printf avec un
format-string adéquat. (ce qui fait que certaines implémentations se
contentent de synthétiser un format-string à partir des paramètres du
stream et de passer la main à printf).
Enfin bref, pour connaitre le formattage des streams C++, il faut connaître
celui de printf.
Justement. A priori, les lecteurs de fclc++ ne connaissent pas grand-chose à printf et compagnie (sauf s'ils ont fait du C avant),
printf est un mauvais exemple, en fait la norme décrit le résultat du formattage des nombres en termes de résultat d'un printf avec un format-string adéquat. (ce qui fait que certaines implémentations se contentent de synthétiser un format-string à partir des paramètres du stream et de passer la main à printf). Enfin bref, pour connaitre le formattage des streams C++, il faut connaître celui de printf.
-- Sam
Samuel Krempp
le Sunday 05 October 2003 21:14, écrivit :
"Samuel Krempp" a écrit dans le message news: 3f80531a$0$2788$
-- Sam fan club MB - sinon la pulpe, elle reste en bas.
:-)
T'as payé ta cotisation ? Bon, c'est gratos pour les 10 premiers.
ah mais ça se passe pas comme ça ! autant que je sache, si je concrétisais l'existence de ce club, devenant son fondateur, je pourrais en fixer le fonctionnement moi même. (probablement avec des contraintes de but non lucratif -aucune possibilité de faire fortune grâce aux cotisations. à moins de faire une structure lourde, de vraie société) pff, de toute façon c trop de paperasse pour moi..
-- Sam
le Sunday 05 October 2003 21:14, _mbinder@magicnet.com écrivit :
"Samuel Krempp" <krempp@crans.truc.en.trop.ens-cachan.fr> a écrit dans le
message news: 3f80531a$0$2788$626a54ce@news.free.fr...
--
Sam
fan club MB - sinon la pulpe, elle reste en bas.
:-)
T'as payé ta cotisation ?
Bon, c'est gratos pour les 10 premiers.
ah mais ça se passe pas comme ça ! autant que je sache, si je concrétisais
l'existence de ce club, devenant son fondateur, je pourrais en fixer le
fonctionnement moi même. (probablement avec des contraintes de but non
lucratif -aucune possibilité de faire fortune grâce aux cotisations. à
moins de faire une structure lourde, de vraie société)
pff, de toute façon c trop de paperasse pour moi..
"Samuel Krempp" a écrit dans le message news: 3f80531a$0$2788$
-- Sam fan club MB - sinon la pulpe, elle reste en bas.
:-)
T'as payé ta cotisation ? Bon, c'est gratos pour les 10 premiers.
ah mais ça se passe pas comme ça ! autant que je sache, si je concrétisais l'existence de ce club, devenant son fondateur, je pourrais en fixer le fonctionnement moi même. (probablement avec des contraintes de but non lucratif -aucune possibilité de faire fortune grâce aux cotisations. à moins de faire une structure lourde, de vraie société) pff, de toute façon c trop de paperasse pour moi..
-- Sam
kanze
Gabriel Dos Reis wrote in message news:...
James Kanze writes:
[...]
| Tout à fait. Il a proposé une correction, mais je ne vois toujours | pas comment l'appel de set_value est légal, même après sa | correction.
Après la correction, c'est valide en C++, invalide en C90, et undefined behaviour en C99.
Alors, il y a un truc que je ne comprends pas, ou que j'ai mal vu. Après la correction, on a :
struct Point { int coord[ 2 ] ; } ;
void print_value( int* p ) { printf( "%d", p ) ; }
int* set_value( int* p, int v ) { *p = v ; return p ; }
struct Point make_point( int a, int b ) { struct Point p = { a, b } ; return p ; }
Alors, make_point renvoie un struct Point, et set_value exige un int* comme premier paramètre. Comment ça peut marcher, que ce soit en C ou en 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
Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> wrote in message
news:<flpthbpsph.fsf@sel.cmla.ens-cachan.fr>...
James Kanze <kanze@alex.gabi-soft.fr> writes:
[...]
| Tout à fait. Il a proposé une correction, mais je ne vois toujours
| pas comment l'appel de set_value est légal, même après sa
| correction.
Après la correction, c'est valide en C++, invalide en C90, et
undefined behaviour en C99.
Alors, il y a un truc que je ne comprends pas, ou que j'ai mal vu. Après
la correction, on a :
struct Point
{
int coord[ 2 ] ;
} ;
void print_value( int* p )
{
printf( "%d", p ) ;
}
int* set_value( int* p, int v )
{
*p = v ;
return p ;
}
struct Point make_point( int a, int b )
{
struct Point p = { a, b } ;
return p ;
}
Alors, make_point renvoie un struct Point, et set_value exige un int*
comme premier paramètre. Comment ça peut marcher, que ce soit en C ou en
C++ ?
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
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
Alors, make_point renvoie un struct Point, et set_value exige un int* comme premier paramètre. Comment ça peut marcher, que ce soit en C ou en 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
Gabriel Dos Reis
writes:
| et dans main : | | print_value( set_value( make_point( 3, 4 ), 8 ) ) ; ^
".coord"
-- Gaby
kanze@gabi-soft.fr writes:
| et dans main :
|
| print_value( set_value( make_point( 3, 4 ), 8 ) ) ;
^
| et dans main : | | print_value( set_value( make_point( 3, 4 ), 8 ) ) ; ^
".coord"
-- Gaby
kanze
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.
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.
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++.
| |> 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.
-- 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
Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> wrote in message
news:<flu16npsr1.fsf@sel.cmla.ens-cachan.fr>...
James Kanze <kanze@alex.gabi-soft.fr> 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.
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.
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++.
| |> 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.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
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
| 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.
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.
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++.
| |> 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.
-- 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
