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++ Argument de fonction par default

Argument de fonction par default

22 réponses
Avatar
Tanski Mikael
Hello,

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...
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
1 2 3
Avatar
Alexandre
"Tanski Mikael" a écrit dans le message de
news:bsko4p$int$
Hello,

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

Tu ne peux pas.

Les paramètres non utilisés de la fonction doivent être les derniers...
Désolé.

Avatar
Christophe Lephay
Alexandre wrote:
"Tanski Mikael" a écrit dans le
message de news:bsko4p$int$
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...

Tu ne peux pas.

Les paramètres non utilisés de la fonction doivent être les
derniers... Désolé.


Enfin tu peux toujours te créer une nouvelle fonction create qui ne prend
pas de paramètre lEvent et qui appelle ta fonction avec FD_READ | FD_WRITE |
FD_OOB | FD_ACCEPT |
FD_CONNECT | FD_CLOSE...

Chris


Avatar
Pierre Maurette
"Tanski Mikael" a écrit
[...]
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...
Bonjour,

Si c'est juste pour cette raison, pourquoi pas un truc genre:
#define FD_ALL FD_READ | FD_WRITE | FD_OOB | FD_ACCEPT | FD_CONNECT |
FD_CLOSE
(inutile de passer par une constante ou un enum, si les constantes FD_xxx
sont des #define, comme c'est la cas dans winsock.h)
Sinon, ça fait certainement 63, c'est encore plus courts à typer, mais c'est
horrible (et peut-être pas sûr) ....
Pierre

Avatar
Fabien LE LEZ
On Sun, 28 Dec 2003 13:59:07 +0100, "Pierre Maurette"
<mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote:

Si c'est juste pour cette raison, pourquoi pas un truc genre:
#define FD_ALL FD_READ | FD_WRITE | FD_OOB | FD_ACCEPT | FD_CONNECT |
FD_CLOSE
(inutile de passer par une constante ou un enum, si les constantes FD_xxx
sont des #define, comme c'est la cas dans winsock.h)


Là, je ne suis pas d'accord.
Il y a des erreurs dans le "standard" qu'est l'API Windows, mais comme
cette API est réputée connue de tous ceux qui l'utilisent, on peut
être sûr que tout programme Win32 sera fait en prenant en compte ces
erreurs (en l'occurence, le fait que FD_READ soit une macro).
Par contre, tu n'as AMHA pas le droit d'ajouter tes propres erreurs,
qui ne seront pas forcément connues des éventuels utilisateurs de ton
code.

--
;-)

Avatar
drkm
"Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> writes:

"Tanski Mikael" a écrit

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


Si c'est juste pour cette raison, pourquoi pas un truc genre:
#define FD_ALL FD_READ | FD_WRITE | FD_OOB | FD_ACCEPT | FD_CONNECT |
FD_CLOSE

(inutile de passer par une constante ou un enum, si les
constantes FD_xxx sont des #define, comme c'est la cas dans
winsock.h)


?

Sinon, ça fait certainement 63, c'est encore plus courts à typer,
mais c'est horrible (et peut-être pas sûr) ....


*Peut-être* pas sûr ? Quel est l'intérêt de définir des constantes
symboliques, alors ? Si les auteurs avaient voulu que l'on saisisse
"63", il auraient dit "saisissez 63, plutôt qu'une chaîne de 62
caractères" ...

--drkm


Avatar
Pierre Maurette
"Fabien LE LEZ" a écrit ...
On Sun, 28 Dec 2003 13:59:07 +0100, "Pierre Maurette"
<mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote:

Si c'est juste pour cette raison, pourquoi pas un truc genre:
#define FD_ALL FD_READ | FD_WRITE | FD_OOB | FD_ACCEPT | FD_CONNECT |
FD_CLOSE
(inutile de passer par une constante ou un enum, si les constantes FD_xxx
sont des #define, comme c'est la cas dans winsock.h)


Là, je ne suis pas d'accord.
Il y a des erreurs dans le "standard" qu'est l'API Windows, mais comme
cette API est réputée connue de tous ceux qui l'utilisent, on peut
être sûr que tout programme Win32 sera fait en prenant en compte ces
erreurs (en l'occurence, le fait que FD_READ soit une macro).
Par contre, tu n'as AMHA pas le droit d'ajouter tes propres erreurs,
qui ne seront pas forcément connues des éventuels utilisateurs de ton
code.
Je ne voyais pas quoi écrire d'autre qu'un #define si les FD_READ etc. sont

eux-mêmes des macros.
En fait, en réfléchissant à la lecture de votre message, je m'apperçois
qu'il faut aller plus loin : quelle que soit la façon dont sont définis les
FD_xxx, c'est un #define qu'il FAUT utiliser : le but est de pouvoir typer
FD_ALL en lieu et place de FD_READ | ... | FD_CLOSE. Ainsi, après le travail
du prétraitement, je ne modifie en rien le fonctionnement, le type, je n'ai
pas à connaitre le contenu du winsock.h et je suis résistant à sa
modification dans de futures versions de l'API.
Pierre


Avatar
Pierre Maurette
"drkm" <fr.comp.lang.c++@fgeorges.org> a écrit
"Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> writes:
[...]

(inutile de passer par une constante ou un enum, si les
constantes FD_xxx sont des #define, comme c'est la cas dans
winsock.h)


?
Voir la réponse faite à Fabien.


Sinon, ça fait certainement 63, c'est encore plus courts à typer,
mais c'est horrible (et peut-être pas sûr) ....
Je devrais utiliser plus souvent la parenthèse rigolarde ;-)



*Peut-être* pas sûr ? Quel est l'intérêt de définir des constantes
symboliques, alors ? Si les auteurs avaient voulu que l'on saisisse
"63", il auraient dit "saisissez 63, plutôt qu'une chaîne de 62
caractères" ...
Oeuf corse, bien sûr ...

Sous Windows, il est pratiquement impératif de ne pas être créatif et de
travailler par copier/coller des prototypes, et même des squelettes.
C'est ainsi qu'on a des chances de ne pas être trop embêté lors de
l'évolution des versions.
La gestion des compatibiltés ascendantes (l'exe tourne sur les nouvelles
versions) et descendante (je compile un code compatible 98 sur une machine
XP avec un SDK up to date) est assez joviale (cf tapi.h).
Pierre


Avatar
Fabien LE LEZ
On Wed, 31 Dec 2003 04:21:33 +0100, "Pierre Maurette"
<mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote:

En fait, en réfléchissant à la lecture de votre message, je m'apperçois
qu'il faut aller plus loin : quelle que soit la façon dont sont définis les
FD_xxx, c'est un #define qu'il FAUT utiliser : le but est de pouvoir typer
FD_ALL en lieu et place de FD_READ | ... | FD_CLOSE. Ainsi, après le travail
du prétraitement, je ne modifie en rien le fonctionnement, le type, je n'ai
pas à connaitre le contenu du winsock.h et je suis résistant à sa
modification dans de futures versions de l'API.


... sauf la version qui #définira un FD_ALL différent du tien.

On sait par contre que l'argument lEvent est un long (et le restera
vraisemblablement), on peut donc créer une constante "locale" de type
"long", égale à FD_READ | ... | FD_CLOSE.

--
;-)

http://www.gotw.ca/gotw/063.htm
http://www.gotw.ca/gotw/067.htm#2

Avatar
drkm
"Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> writes:

"drkm" <fr.comp.lang.c++@fgeorges.org> a écrit

?


Voir la réponse faite à Fabien.


J'y cours ...

--drkm


Avatar
drkm
"Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> writes:

"Fabien LE LEZ" a écrit ...

Là, je ne suis pas d'accord.
Il y a des erreurs dans le "standard" qu'est l'API Windows, mais comme
cette API est réputée connue de tous ceux qui l'utilisent, on peut
être sûr que tout programme Win32 sera fait en prenant en compte ces
erreurs (en l'occurence, le fait que FD_READ soit une macro).
Par contre, tu n'as AMHA pas le droit d'ajouter tes propres erreurs,
qui ne seront pas forcément connues des éventuels utilisateurs de ton
code.


Je ne voyais pas quoi écrire d'autre qu'un #define si les FD_READ etc. sont
eux-mêmes des macros.


int const unNomQuiVaBien = FD_READ | FD_... ;

Où est le problème ?

En fait, en réfléchissant à la lecture de votre message, je
m'apperçois qu'il faut aller plus loin : quelle que soit la façon
dont sont définis les FD_xxx, c'est un #define qu'il FAUT utiliser :


?

le but est de pouvoir typer FD_ALL en lieu et place de FD_READ |
... | FD_CLOSE. Ainsi, après le travail du prétraitement, je ne
modifie en rien le fonctionnement, le type,


?

je n'ai pas à connaitre le contenu du winsock.h et je suis résistant
à sa modification dans de futures versions de l'API.


?

--drkm


1 2 3