Alors voila j'ai cette définition de fonction :
BOOL Create(
UINT nSocketPort = 0,
int nSocketType = SOCK_STREAM,
long lEvent = FD_READ | FD_WRITE | FD_OOB | FD_ACCEPT | FD_CONNECT |
FD_CLOSE,
LPCTSTR lpszSocketAddress = NULL
);
Vous remarquez qu'il y a des arguments par default, notamment lEvent qui
est bien long (en terme de caractéres, pas de type).
Alors voila j'ai besoin de redéfinire tous les arguments sauf lEvent.
Y a til un moyen de faire cela en c++? Pour rendre plus clair la chose,
je voudrais pouvoir appeler la fonction un peux comme sa :
Create(80,SOCK_STREAM,,"127.0.0.1");
Je vous demande cela juste pour eviter en faite de recopier la longue
série FD_READ | FD_WRITE | FD_OOB | FD_ACCEPT | FD_CONNECT | FD_CLOSE...
Bon d'accord c'est pas trés clair, mais si quelqu'un voit, merci à lui...
Un code bien pensé doit fonctionner parfaitement presque du premier coup, sans qu'on ait à passer des heures à essayer de comprendre d'où vient tel ou tel bug.
mais dans les fait, son poids en cacahouetes a celui qui y arrive a tous les coups, meme si le code est bien pense :-)
Certes. Mais a part dans certains cas tordus, on peut la plupart du temps s'éviter de longues heures de pénible débogage.
ricky : bonnes resolutions en 2004, plus de troll :-) enfin presque ...
Entre le présent thread et fra, c'est pas gagné :-/
On Thu, 01 Jan 2004 00:50:31 +0100, ricky <eric_nyme@yahoo.fr> wrote:
Un code bien pensé doit fonctionner parfaitement presque du premier
coup, sans qu'on ait à passer des heures à essayer de comprendre d'où
vient tel ou tel bug.
mais dans les fait, son poids en cacahouetes a celui qui y arrive a tous
les coups, meme si le code est bien pense :-)
Certes. Mais a part dans certains cas tordus, on peut la plupart du
temps s'éviter de longues heures de pénible débogage.
ricky : bonnes resolutions en 2004, plus de troll :-) enfin presque ...
Entre le présent thread et fra, c'est pas gagné :-/
Un code bien pensé doit fonctionner parfaitement presque du premier coup, sans qu'on ait à passer des heures à essayer de comprendre d'où vient tel ou tel bug.
mais dans les fait, son poids en cacahouetes a celui qui y arrive a tous les coups, meme si le code est bien pense :-)
Certes. Mais a part dans certains cas tordus, on peut la plupart du temps s'éviter de longues heures de pénible débogage.
ricky : bonnes resolutions en 2004, plus de troll :-) enfin presque ...
Entre le présent thread et fra, c'est pas gagné :-/
On Wed, 31 Dec 2003 08:46:26 +0100, "Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote:
int const unNomQuiVaBien = FD_READ | FD_... ;
Où est le problème ? Pourquoi "int" ?
C'est effectivement une erreur. Le type réclamé par la fonction est long, donc la variable unNomQuiVaBien devrait être de ce type.
J'ai en effet répondu un peu vite. C'est le désavantage de ne pas avoir de connexion à domicile, et de surveiller l'orloge où l'on paie pour se connecter :-(
Mais ma réponse reste la même en substance. Pierre ne voyait pas quoi utiliser si les valeurs de départ étaient des macros. Après précompilation, le token aura de toute façon un type, il "suffit" d'utiliser le même. Il y a déjà eu une discussion fournie sur le type à utiliser pour la valeur de `__LINE__´, ici-même, qui serait intéressante dans ce cadre.
--drkm
Fabien LE LEZ <gramster@gramster.com> wrote in message news:<fmb6vvg5h3efg52bq6g8sbph1cs4pj53l1@4ax.com>...
On Wed, 31 Dec 2003 08:46:26 +0100, "Pierre Maurette"
<mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote:
int const unNomQuiVaBien = FD_READ | FD_... ;
Où est le problème ?
Pourquoi "int" ?
C'est effectivement une erreur.
Le type réclamé par la fonction est long, donc la variable
unNomQuiVaBien devrait être de ce type.
J'ai en effet répondu un peu vite. C'est le désavantage de ne pas
avoir de connexion à domicile, et de surveiller l'orloge où l'on paie
pour se connecter :-(
Mais ma réponse reste la même en substance. Pierre ne voyait pas
quoi utiliser si les valeurs de départ étaient des macros. Après
précompilation, le token aura de toute façon un type, il "suffit"
d'utiliser le même. Il y a déjà eu une discussion fournie sur le type
à utiliser pour la valeur de `__LINE__´, ici-même, qui serait
intéressante dans ce cadre.
On Wed, 31 Dec 2003 08:46:26 +0100, "Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote:
int const unNomQuiVaBien = FD_READ | FD_... ;
Où est le problème ? Pourquoi "int" ?
C'est effectivement une erreur. Le type réclamé par la fonction est long, donc la variable unNomQuiVaBien devrait être de ce type.
J'ai en effet répondu un peu vite. C'est le désavantage de ne pas avoir de connexion à domicile, et de surveiller l'orloge où l'on paie pour se connecter :-(
Mais ma réponse reste la même en substance. Pierre ne voyait pas quoi utiliser si les valeurs de départ étaient des macros. Après précompilation, le token aura de toute façon un type, il "suffit" d'utiliser le même. Il y a déjà eu une discussion fournie sur le type à utiliser pour la valeur de `__LINE__´, ici-même, qui serait intéressante dans ce cadre.
