J'essaye de faire un wrapper c++ pour la fonction select c et je suis tombé sur la définition des fd_set. C'est une structure qui contient un array de long int...

Une raison particulière ou je peux créer ma propre array de long int dans mon coin et l'utiliser gentillement comme un "vrai" fd_set... Ca me simplifierait la vie

J'ai souvent du mal à comprendre tes questions Altar...
Mais peut-être qu'il n'y a pas de question puisqu'il n'y a pas de point d'interrogation ?


C'est moi ou il y en a d'autres ?

Il demande s'il peut utiliser sa propre array de long int dans son coin, et l'utiliser come un "vrai" fd_set

Ovh a très bien compris ma question Essayons d'être plus clair. Est-ce que la structure fd_set a une raison d'être ou un array de long int peut très bien la remplacer ? C'est plus clair ?

La structure fd_set permet d'isoler la définition d'un API de son implémentation.
Si tu sais que c'est un array de long int, c'est parce que tu es allé lire le fichier <sys/select.h>.

Si tu utilises ton propre array, tu crées du code dépendant de la version de ton compilateur, et de ta version de l'OS. Ça peut marcher presque tout le temps, mais ça peut foirer aussi, et ce n'est certainement pas une bonne façon de programmer. J'espère que tu ne t'amuses pas non plus à voir ce qu'il y a dans un FILE * et à y chipoter...

Idéalement, ce genre de structure devrait être opaque, déclarée par un typedef abstrait dans l'include, et définie dans l'implémentation.
Mais le fait que FD_CLR, FD_ISSET etc. sont implémentés comme des macros empêche de faire cette abstraction.

Que veux-tu faire avec cette structure en dehors de l'utiliser dans les API de select ?

philfr> Et que penser des connards qui exportent des fd_set dans des fonctions à leur librairie sachant que tout le monde n'utilise pas le même compilateur ni même le même langage?

Utiliser le type fd_set est safe, puisqu'on l'utilise avec les API faits pour, et que si on recompile sur un autre OS/compilo, ça doit marcher par définition.

Faire la supposition que fd_set est une structure d'arrays de long et utiliser ça à la place ne l'est pas (safe)...

Edit: delphi ne supporte pas le select ?

philfr > J'aimerais bien retrouver le plus grand fd à partir du fd_set (pour la première variable de select).

Je peux faire le porc dans l'autre sens et créer un fd_set puis le caster comme un pointeur de long et faire mes opérations dessus si tu trouves que c'est plus safe...

Négatif, ce type n'existe pas sous Delphi

Le jour où j'ai dû l'utiliser j'ai bien été obligé de faire mon array de long à la place

C'est toi qui donnes les fd, donc tu fixes n à la valeur du plus grand fd+1.
Si tu reçois le fd_set d'un autre API (d'où ça ?), c'est lui qui doit te donner ce n.



C'est presque pire
Mais tu ne devrais pas avoir d'autres opérations à faire que celles implémentées dans les macros standard.

philfr > C'est moi qui donne les fd Mais je ne les donne qu'une fois et je crée une copie de mon fd_set "original" avant chaque appel à select. Malheureusement après si je décide de retirer le plus grand fd, je ne sais pas retrouver le suivant à moins de parcourir mon fd_set...

Oui je pourrais créer une structure qui ressemble vachement à un fd_set et puis faire plein de FD_SET(fd,&fd_set) mais je pense que la copie d'un array de long ira plus vite que la mise à jour bit par bit

C'est pas grave si le n que tu donnes est supérieur au plus grand fd. C'est juste un hint pour que le kernel ne doive pas parcourir toute l'array... ce qui est précisément ce que tu veux faire à sa place.

Augmente n si nécessaire à chaque fois que tu ajoutes un fd, mais ne le diminue jamais...

Ou alors, reconstruis un nouveau fd_set à partir de la liste des fd que tu as dans ton array (tu les as bien quelque part, non ?) avant chaque appel à select. Ce sera toujours plus efficace que de reparcourir le fd_set brut.

Au fait, si tu développe avec select() sous linux 2.6, jette donc un coup d'oeil à epoll()...

Hum merci du tuyeau, je vais regarder ça tantôt

Epoll en level triggered a l'air bien

Et bientôt, pour linux on aura kevent...