En fait, si je les ait écrites, c'est justement dans ce but après avoir passer des heures à ne pas trouver les classes qui me convenaient : trop complètes en général.
Est-ce que ça t'intéresse que tes classes supportent Windows ? Pour l'instant, elles ne supportent qu'Unix. Je peux te le faire, mais faudra pas être pressé.
Je ne suis pas contre, avec la seule restriction que ça reste simple :). D'ailleurs, je pense que le plus simple serait d'écrire une version windows dans un fichier .cpp complètement différent, mais avec la même fichier interface .h.
Ne connaissant absolument pas les API socket windows (sauf quelles ressembles de très près à celle POSIX, mais en étant incompatible, ce qui est bien dommage), je te laisserais le loisir de faire ce que tu veux :).
Le code actuel est surtout un wrapper vers les API POSIX standard d'unix avec : - la gestion du relancement des appels systèmes interrompus, lorsque le programme reçoit un signal (un truc subtile auquel on ne pense pas souvent, mais qui est souvent à l'origine de bugs incompréhensibles). - une simplification des codes d'erreurs, et l'utilisation d'exceptions (je doit avoir maximum 3 types d'exceptions pour les sockets, alors qu'il y a une bonne vingtaine de code d'erreur, parfois assez redondant) - les traitements classiques à effectuer pour certaines erreurs (par exemple le relancement d'un appel système interrompu, ). - j'utilise la bibliothèque standard du C++ (surtout pour les strings), sans en réécrire une équivalente comme c'est le cas dans nombre de projets. - un système super compliqué pour permettre d'interrompre un appel en cour (utile pour interrompre une tâche, sachant par exemple qu'un read peut être bloquant tant qu'il n'y a pas de données accessibles).
-- Schmurtz
bernard tatin <bernard.tatin@nospam.tele2.fr.invalid> wrote:
En fait, si je les ait écrites, c'est justement dans ce but après avoir
passer des heures à ne pas trouver les classes qui me convenaient : trop
complètes en général.
Est-ce que ça t'intéresse que tes classes supportent Windows ? Pour
l'instant, elles ne supportent qu'Unix. Je peux te le faire, mais faudra
pas être pressé.
Je ne suis pas contre, avec la seule restriction que ça reste simple :).
D'ailleurs, je pense que le plus simple serait d'écrire une version
windows dans un fichier .cpp complètement différent, mais avec la même
fichier interface .h.
Ne connaissant absolument pas les API socket windows (sauf quelles
ressembles de très près à celle POSIX, mais en étant incompatible, ce
qui est bien dommage), je te laisserais le loisir de faire ce que tu
veux :).
Le code actuel est surtout un wrapper vers les API POSIX standard d'unix
avec :
- la gestion du relancement des appels systèmes interrompus, lorsque le
programme reçoit un signal (un truc subtile auquel on ne pense pas
souvent, mais qui est souvent à l'origine de bugs incompréhensibles).
- une simplification des codes d'erreurs, et l'utilisation d'exceptions
(je doit avoir maximum 3 types d'exceptions pour les sockets, alors
qu'il y a une bonne vingtaine de code d'erreur, parfois assez redondant)
- les traitements classiques à effectuer pour certaines erreurs (par
exemple le relancement d'un appel système interrompu, ).
- j'utilise la bibliothèque standard du C++ (surtout pour les strings),
sans en réécrire une équivalente comme c'est le cas dans nombre de
projets.
- un système super compliqué pour permettre d'interrompre un appel en
cour (utile pour interrompre une tâche, sachant par exemple qu'un read
peut être bloquant tant qu'il n'y a pas de données accessibles).
En fait, si je les ait écrites, c'est justement dans ce but après avoir passer des heures à ne pas trouver les classes qui me convenaient : trop complètes en général.
Est-ce que ça t'intéresse que tes classes supportent Windows ? Pour l'instant, elles ne supportent qu'Unix. Je peux te le faire, mais faudra pas être pressé.
Je ne suis pas contre, avec la seule restriction que ça reste simple :). D'ailleurs, je pense que le plus simple serait d'écrire une version windows dans un fichier .cpp complètement différent, mais avec la même fichier interface .h.
Ne connaissant absolument pas les API socket windows (sauf quelles ressembles de très près à celle POSIX, mais en étant incompatible, ce qui est bien dommage), je te laisserais le loisir de faire ce que tu veux :).
Le code actuel est surtout un wrapper vers les API POSIX standard d'unix avec : - la gestion du relancement des appels systèmes interrompus, lorsque le programme reçoit un signal (un truc subtile auquel on ne pense pas souvent, mais qui est souvent à l'origine de bugs incompréhensibles). - une simplification des codes d'erreurs, et l'utilisation d'exceptions (je doit avoir maximum 3 types d'exceptions pour les sockets, alors qu'il y a une bonne vingtaine de code d'erreur, parfois assez redondant) - les traitements classiques à effectuer pour certaines erreurs (par exemple le relancement d'un appel système interrompu, ). - j'utilise la bibliothèque standard du C++ (surtout pour les strings), sans en réécrire une équivalente comme c'est le cas dans nombre de projets. - un système super compliqué pour permettre d'interrompre un appel en cour (utile pour interrompre une tâche, sachant par exemple qu'un read peut être bloquant tant qu'il n'y a pas de données accessibles).
-- Schmurtz
bernard tatin
bernard tatin wrote:
En fait, si je les ait écrites, c'est justement dans ce but après avoir passer des heures à ne pas trouver les classes qui me convenaient : trop complètes en général.
Est-ce que ça t'intéresse que tes classes supportent Windows ? Pour l'instant, elles ne supportent qu'Unix. Je peux te le faire, mais faudra pas être pressé.
Je ne suis pas contre, avec la seule restriction que ça reste simple :). C'est le but de la manip.
D'ailleurs, je pense que le plus simple serait d'écrire une version windows dans un fichier .cpp complètement différent, mais avec la même fichier interface .h.
Pour les sockets, certainement, mais pour les threads, ce n'est pas forcément obligé.
Ne connaissant absolument pas les API socket windows (sauf quelles ressembles de très près à celle POSIX, mais en étant incompatible, ce qui est bien dommage), je te laisserais le loisir de faire ce que tu veux :).
OK
Le code actuel est surtout un wrapper vers les API POSIX standard d'unix avec : - la gestion du relancement des appels systèmes interrompus, lorsque le programme reçoit un signal (un truc subtile auquel on ne pense pas souvent, mais qui est souvent à l'origine de bugs incompréhensibles). - une simplification des codes d'erreurs, et l'utilisation d'exceptions (je doit avoir maximum 3 types d'exceptions pour les sockets, alors qu'il y a une bonne vingtaine de code d'erreur, parfois assez redondant) - les traitements classiques à effectuer pour certaines erreurs (par exemple le relancement d'un appel système interrompu, ). - j'utilise la bibliothèque standard du C++ (surtout pour les strings), sans en réécrire une équivalente comme c'est le cas dans nombre de projets. C'est très bien, ça.
- un système super compliqué pour permettre d'interrompre un appel en cour (utile pour interrompre une tâche, sachant par exemple qu'un read peut être bloquant tant qu'il n'y a pas de données accessibles).
Alors, c'est parti. Mais comme je l'ai déjà dit, faudra pas être trop pressé : j'ai du boulot et, surtout, je n'ai pas toujours de Windows à disposition (Mac OS, Linux, FreeBSD ...).
A bientôt, Bernard.
bernard tatin <bernard.tatin@nospam.tele2.fr.invalid> wrote:
En fait, si je les ait écrites, c'est justement dans ce but après avoir
passer des heures à ne pas trouver les classes qui me convenaient : trop
complètes en général.
Est-ce que ça t'intéresse que tes classes supportent Windows ? Pour
l'instant, elles ne supportent qu'Unix. Je peux te le faire, mais faudra
pas être pressé.
Je ne suis pas contre, avec la seule restriction que ça reste simple :).
C'est le but de la manip.
D'ailleurs, je pense que le plus simple serait d'écrire une version
windows dans un fichier .cpp complètement différent, mais avec la même
fichier interface .h.
Pour les sockets, certainement, mais pour les threads, ce n'est pas
forcément obligé.
Ne connaissant absolument pas les API socket windows (sauf quelles
ressembles de très près à celle POSIX, mais en étant incompatible, ce
qui est bien dommage), je te laisserais le loisir de faire ce que tu
veux :).
OK
Le code actuel est surtout un wrapper vers les API POSIX standard d'unix
avec :
- la gestion du relancement des appels systèmes interrompus, lorsque le
programme reçoit un signal (un truc subtile auquel on ne pense pas
souvent, mais qui est souvent à l'origine de bugs incompréhensibles).
- une simplification des codes d'erreurs, et l'utilisation d'exceptions
(je doit avoir maximum 3 types d'exceptions pour les sockets, alors
qu'il y a une bonne vingtaine de code d'erreur, parfois assez redondant)
- les traitements classiques à effectuer pour certaines erreurs (par
exemple le relancement d'un appel système interrompu, ).
- j'utilise la bibliothèque standard du C++ (surtout pour les strings),
sans en réécrire une équivalente comme c'est le cas dans nombre de
projets.
C'est très bien, ça.
- un système super compliqué pour permettre d'interrompre un appel en
cour (utile pour interrompre une tâche, sachant par exemple qu'un read
peut être bloquant tant qu'il n'y a pas de données accessibles).
Alors, c'est parti. Mais comme je l'ai déjà dit, faudra pas être trop
pressé : j'ai du boulot et, surtout, je n'ai pas toujours de Windows à
disposition (Mac OS, Linux, FreeBSD ...).
En fait, si je les ait écrites, c'est justement dans ce but après avoir passer des heures à ne pas trouver les classes qui me convenaient : trop complètes en général.
Est-ce que ça t'intéresse que tes classes supportent Windows ? Pour l'instant, elles ne supportent qu'Unix. Je peux te le faire, mais faudra pas être pressé.
Je ne suis pas contre, avec la seule restriction que ça reste simple :). C'est le but de la manip.
D'ailleurs, je pense que le plus simple serait d'écrire une version windows dans un fichier .cpp complètement différent, mais avec la même fichier interface .h.
Pour les sockets, certainement, mais pour les threads, ce n'est pas forcément obligé.
Ne connaissant absolument pas les API socket windows (sauf quelles ressembles de très près à celle POSIX, mais en étant incompatible, ce qui est bien dommage), je te laisserais le loisir de faire ce que tu veux :).
OK
Le code actuel est surtout un wrapper vers les API POSIX standard d'unix avec : - la gestion du relancement des appels systèmes interrompus, lorsque le programme reçoit un signal (un truc subtile auquel on ne pense pas souvent, mais qui est souvent à l'origine de bugs incompréhensibles). - une simplification des codes d'erreurs, et l'utilisation d'exceptions (je doit avoir maximum 3 types d'exceptions pour les sockets, alors qu'il y a une bonne vingtaine de code d'erreur, parfois assez redondant) - les traitements classiques à effectuer pour certaines erreurs (par exemple le relancement d'un appel système interrompu, ). - j'utilise la bibliothèque standard du C++ (surtout pour les strings), sans en réécrire une équivalente comme c'est le cas dans nombre de projets. C'est très bien, ça.
- un système super compliqué pour permettre d'interrompre un appel en cour (utile pour interrompre une tâche, sachant par exemple qu'un read peut être bloquant tant qu'il n'y a pas de données accessibles).
Alors, c'est parti. Mais comme je l'ai déjà dit, faudra pas être trop pressé : j'ai du boulot et, surtout, je n'ai pas toujours de Windows à disposition (Mac OS, Linux, FreeBSD ...).
A bientôt, Bernard.
Schmurtz
bernard tatin wrote:
Alors, c'est parti. Mais comme je l'ai déjà dit, faudra pas être trop pressé : j'ai du boulot et, surtout, je n'ai pas toujours de Windows à disposition (Mac OS, Linux, FreeBSD ...).
Bon courage alors ;)
-- Schmurtz
bernard tatin <bernard.tatin@nospam.tele2.fr.invalid> wrote:
Alors, c'est parti. Mais comme je l'ai déjà dit, faudra pas être trop
pressé : j'ai du boulot et, surtout, je n'ai pas toujours de Windows à
disposition (Mac OS, Linux, FreeBSD ...).
Alors, c'est parti. Mais comme je l'ai déjà dit, faudra pas être trop pressé : j'ai du boulot et, surtout, je n'ai pas toujours de Windows à disposition (Mac OS, Linux, FreeBSD ...).
