Je suis étudiant en DUT Informatique, et je programme un peu en dehors
des cours pour m'entrainer, voici donc quelques questions.
1) J'aimerais faire une petite application qui se connecte à un serveur
IRC, donc via des sockets TCP. Seulement je me heurte à quelques problèmes:
- Y a t'il des bibliothèques portables qui me permettent de gérer plus
facilement les sockets? L'idée c'est que le code sois facilement
compilable d'une platforme à une autre.
Je sais que c'est possible avec Qt par exemple, mais ça me parait un peu
lourd, puisque si je commence à utiliser Qt, je vais utiliser tous
l'arsenal qui va avec (QSring, QList etc...), et je souhaiterais
utiliser un maximum la STL.
- Comment gérer le "main loop", je ne sais pas trop comment ça
fonctionne, car si je ne fais pas une boucle infinie (while true?) mon
programme arrete de s'éxécuter (normal me direz-vous...).
Alors comment puis-je empecher mon programme de s'arreter? Je cherche la
manière la plus propre possible. Encore une fois Qt permet ça facilement
puisque de base il y a un "event loop" qui gère ça, mais j'aimerais peut
voir d'autres méthodes.
2) Comment puis-je placer mon application en "fond", c'est à dire
qu'elle rende la main une fois qu'elle a été démarée. Idem, je cherche
une solution portable !
On Fri, 13 Mar 2009 02:21:49 -0700 (PDT), James Kanze :
Tu crées donc un thread par connexion (pour que l'attente sur une connection ne bloque pas toute l'application)
Il me semble qu'il n'y a ici qu'une seule connexion, et qu'on veut justement que l'attente bloque l'application. Mais bon, sans en savoir plus sur les intentions de l'OP, c'est difficile de décider.
On Fri, 13 Mar 2009 02:21:49 -0700 (PDT), James Kanze
<james.kanze@gmail.com>:
Tu crées
donc un thread par connexion (pour que l'attente sur une
connection ne bloque pas toute l'application)
Il me semble qu'il n'y a ici qu'une seule connexion, et qu'on veut
justement que l'attente bloque l'application.
Mais bon, sans en savoir plus sur les intentions de l'OP, c'est
difficile de décider.
On Fri, 13 Mar 2009 02:21:49 -0700 (PDT), James Kanze :
Tu crées donc un thread par connexion (pour que l'attente sur une connection ne bloque pas toute l'application)
Il me semble qu'il n'y a ici qu'une seule connexion, et qu'on veut justement que l'attente bloque l'application. Mais bon, sans en savoir plus sur les intentions de l'OP, c'est difficile de décider.
James Kanze
On Mar 13, 10:47 am, (Marc Espie) wrote:
In article , James Kanze wrote:
>Je crois que Boost.Asio s'adresse à un autre problème, des >entrées/sorties non bloquantes. Si tu as des threads, il n'y >a pas vraiment de motif à utiliser des entrées/sorties non >bloquantes.
Euh, si, quand meme. Si tu as des interactions entre les diverses entrees-sorties, ca peut etre utile.
Tu veux que je te donne un cas concret qui serait merdique avec des threads? j'ai un make parallele, qui recupere la sortie de plusieurs jobs en parallele. Le boulot du make, c'est d'afficher les choses de facon raisonnable, c'est-a-dire le plus possible de redecouper les entrees distinctes en ligne (mais en restant raisonnablement temps reel, donc si tu as une ligne incomplete, tu l'affiches et basta).
Oui, mais dans ce cas-là, tu n'utilises pas les threads. Il y a peut-être des exceptions, mais en général, ou tu utilises les threads, ou tu utilises select. Je ne vois pas comme ça un cas où utiliser les deux conviendra.
C'est assez simple a faire avec select ET des entrees non bloquantes: je trouve un job qui a des trucs a dire, et je l'"epuise" a coups de read jusqu'a ce qu'il n'en veuille plus, et j'ai un tampon derriere pour gerer les lignes, et garder pour la suite. Puis je passe au suivant (je suis conscient que mon algo n'est pas equitable, mais dans ce cas de figure, ca n'est pas un probleme).
Oui. Dans ton cas, il y a beaucoup d'état commun, et quasiment pas d'état par connexion. Et les résultats d'une connexion joue sur la gestion d'une autre.
Ca serait relativement complexe a faire avec des threads et des mutex:
Complex, non. Chaque thread attendra la fin de sa connexion, puis enverra un message à une boîte à lettres où le thread central attend. Mais ça ferait une couche en plus pour rien.
de facon naive, apres chaque lecture, mon thread prendrait la main pour afficher des lignes completes, puis la rendrait en attendant la lecture (bloquante) suivante. Pas du tout le meme resultat, puisque ca aurait tendance a beaucoup plus entremeler les lignes a niveau de reactivite egale...
On pourrait gerer le problème des lignes entremelées aux coups de mutex. Ou faire les sorties dans le thread principal, voire en avoir un thread dédié. Les solutions n'en manquent pas. Seulement, pourquoi, si ça n'apporte rien ?
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Mar 13, 10:47 am, es...@lain.home (Marc Espie) wrote:
In article
<7f8d8c07-16eb-4336-9894-5a820a8ab...@l39g2000yqn.googlegroups.com>,
James Kanze <james.ka...@gmail.com> wrote:
>Je crois que Boost.Asio s'adresse à un autre problème, des
>entrées/sorties non bloquantes. Si tu as des threads, il n'y
>a pas vraiment de motif à utiliser des entrées/sorties non
>bloquantes.
Euh, si, quand meme. Si tu as des interactions entre les
diverses entrees-sorties, ca peut etre utile.
Tu veux que je te donne un cas concret qui serait merdique
avec des threads? j'ai un make parallele, qui recupere la
sortie de plusieurs jobs en parallele. Le boulot du make,
c'est d'afficher les choses de facon raisonnable, c'est-a-dire
le plus possible de redecouper les entrees distinctes en ligne
(mais en restant raisonnablement temps reel, donc si tu as une
ligne incomplete, tu l'affiches et basta).
Oui, mais dans ce cas-là, tu n'utilises pas les threads. Il y a
peut-être des exceptions, mais en général, ou tu utilises les
threads, ou tu utilises select. Je ne vois pas comme ça un cas
où utiliser les deux conviendra.
C'est assez simple a faire avec select ET des entrees non
bloquantes: je trouve un job qui a des trucs a dire, et je
l'"epuise" a coups de read jusqu'a ce qu'il n'en veuille plus,
et j'ai un tampon derriere pour gerer les lignes, et garder
pour la suite. Puis je passe au suivant (je suis conscient que
mon algo n'est pas equitable, mais dans ce cas de figure, ca
n'est pas un probleme).
Oui. Dans ton cas, il y a beaucoup d'état commun, et quasiment
pas d'état par connexion. Et les résultats d'une connexion joue
sur la gestion d'une autre.
Ca serait relativement complexe a faire avec des threads et
des mutex:
Complex, non. Chaque thread attendra la fin de sa connexion,
puis enverra un message à une boîte à lettres où le thread
central attend. Mais ça ferait une couche en plus pour rien.
de facon naive, apres chaque lecture, mon thread prendrait la
main pour afficher des lignes completes, puis la rendrait en
attendant la lecture (bloquante) suivante. Pas du tout le
meme resultat, puisque ca aurait tendance a beaucoup plus
entremeler les lignes a niveau de reactivite egale...
On pourrait gerer le problème des lignes entremelées aux coups
de mutex. Ou faire les sorties dans le thread principal, voire
en avoir un thread dédié. Les solutions n'en manquent pas.
Seulement, pourquoi, si ça n'apporte rien ?
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
>Je crois que Boost.Asio s'adresse à un autre problème, des >entrées/sorties non bloquantes. Si tu as des threads, il n'y >a pas vraiment de motif à utiliser des entrées/sorties non >bloquantes.
Euh, si, quand meme. Si tu as des interactions entre les diverses entrees-sorties, ca peut etre utile.
Tu veux que je te donne un cas concret qui serait merdique avec des threads? j'ai un make parallele, qui recupere la sortie de plusieurs jobs en parallele. Le boulot du make, c'est d'afficher les choses de facon raisonnable, c'est-a-dire le plus possible de redecouper les entrees distinctes en ligne (mais en restant raisonnablement temps reel, donc si tu as une ligne incomplete, tu l'affiches et basta).
Oui, mais dans ce cas-là, tu n'utilises pas les threads. Il y a peut-être des exceptions, mais en général, ou tu utilises les threads, ou tu utilises select. Je ne vois pas comme ça un cas où utiliser les deux conviendra.
C'est assez simple a faire avec select ET des entrees non bloquantes: je trouve un job qui a des trucs a dire, et je l'"epuise" a coups de read jusqu'a ce qu'il n'en veuille plus, et j'ai un tampon derriere pour gerer les lignes, et garder pour la suite. Puis je passe au suivant (je suis conscient que mon algo n'est pas equitable, mais dans ce cas de figure, ca n'est pas un probleme).
Oui. Dans ton cas, il y a beaucoup d'état commun, et quasiment pas d'état par connexion. Et les résultats d'une connexion joue sur la gestion d'une autre.
Ca serait relativement complexe a faire avec des threads et des mutex:
Complex, non. Chaque thread attendra la fin de sa connexion, puis enverra un message à une boîte à lettres où le thread central attend. Mais ça ferait une couche en plus pour rien.
de facon naive, apres chaque lecture, mon thread prendrait la main pour afficher des lignes completes, puis la rendrait en attendant la lecture (bloquante) suivante. Pas du tout le meme resultat, puisque ca aurait tendance a beaucoup plus entremeler les lignes a niveau de reactivite egale...
On pourrait gerer le problème des lignes entremelées aux coups de mutex. Ou faire les sorties dans le thread principal, voire en avoir un thread dédié. Les solutions n'en manquent pas. Seulement, pourquoi, si ça n'apporte rien ?
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze
On Mar 13, 10:48 am, (Marc Espie) wrote:
In article , James Kanze wrote:
>Pour commencer. Il faut bien aussi se retrouver dans un >groupe de processus à soi (pour ne pas prendre des signaux >destinés à un parent, par exemple), et normalement s'assurer >aussi d'être orphlin (pour ne pas devenir zombie). Et d'être >déconnecté du terminal.
C'est ce que fait le setsid() plus la fermeture des fd 0, 1, 2...
Oui, mais Merwin n'en avait pas parlé. Que de fork() et exit() dans le père.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Mar 13, 10:48 am, es...@lain.home (Marc Espie) wrote:
In article
<556ec9f5-b305-4f33-b6ad-6411d673b...@h20g2000yqn.googlegroups.com>,
James Kanze <james.ka...@gmail.com> wrote:
>Pour commencer. Il faut bien aussi se retrouver dans un
>groupe de processus à soi (pour ne pas prendre des signaux
>destinés à un parent, par exemple), et normalement s'assurer
>aussi d'être orphlin (pour ne pas devenir zombie). Et d'être
>déconnecté du terminal.
C'est ce que fait le setsid() plus la fermeture des fd 0, 1,
2...
Oui, mais Merwin n'en avait pas parlé. Que de fork() et exit()
dans le père.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
>Pour commencer. Il faut bien aussi se retrouver dans un >groupe de processus à soi (pour ne pas prendre des signaux >destinés à un parent, par exemple), et normalement s'assurer >aussi d'être orphlin (pour ne pas devenir zombie). Et d'être >déconnecté du terminal.
C'est ce que fait le setsid() plus la fermeture des fd 0, 1, 2...
Oui, mais Merwin n'en avait pas parlé. Que de fork() et exit() dans le père.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sylvain SF
Fabien LE LEZ a écrit :
Yep, mais dans ce cas, tu implémentes ta propre version d'une bibliothèque (pour apprendre), puis tu la jettes et tu prends une version bien testée.
ouais, y'a aussi tu t'expérimentes le cerveau avec tes propres réflexions, puis tu le jettes et tu prends des idées bien éculées ... zut ça me rappelle un fil récent.
Sylvain.
Fabien LE LEZ a écrit :
Yep, mais dans ce cas, tu implémentes ta propre version d'une
bibliothèque (pour apprendre), puis tu la jettes et tu prends une
version bien testée.
ouais, y'a aussi tu t'expérimentes le cerveau avec tes propres
réflexions, puis tu le jettes et tu prends des idées bien
éculées ... zut ça me rappelle un fil récent.
Yep, mais dans ce cas, tu implémentes ta propre version d'une bibliothèque (pour apprendre), puis tu la jettes et tu prends une version bien testée.
ouais, y'a aussi tu t'expérimentes le cerveau avec tes propres réflexions, puis tu le jettes et tu prends des idées bien éculées ... zut ça me rappelle un fil récent.
Sylvain.
Merwin
Fabien LE LEZ a écrit :
On Fri, 13 Mar 2009 02:21:49 -0700 (PDT), James Kanze :
Tu crées donc un thread par connexion (pour que l'attente sur une connection ne bloque pas toute l'application)
Il me semble qu'il n'y a ici qu'une seule connexion, et qu'on veut justement que l'attente bloque l'application. Mais bon, sans en savoir plus sur les intentions de l'OP, c'est difficile de décider.
C'est en effet le cas, une seule connexion, bloquante. Merci à tous pour vos conseils !
Fabien LE LEZ a écrit :
On Fri, 13 Mar 2009 02:21:49 -0700 (PDT), James Kanze
<james.kanze@gmail.com>:
Tu crées
donc un thread par connexion (pour que l'attente sur une
connection ne bloque pas toute l'application)
Il me semble qu'il n'y a ici qu'une seule connexion, et qu'on veut
justement que l'attente bloque l'application.
Mais bon, sans en savoir plus sur les intentions de l'OP, c'est
difficile de décider.
C'est en effet le cas, une seule connexion, bloquante.
Merci à tous pour vos conseils !
On Fri, 13 Mar 2009 02:21:49 -0700 (PDT), James Kanze :
Tu crées donc un thread par connexion (pour que l'attente sur une connection ne bloque pas toute l'application)
Il me semble qu'il n'y a ici qu'une seule connexion, et qu'on veut justement que l'attente bloque l'application. Mais bon, sans en savoir plus sur les intentions de l'OP, c'est difficile de décider.
C'est en effet le cas, une seule connexion, bloquante. Merci à tous pour vos conseils !
Merwin
James Kanze a écrit :
On Mar 13, 10:48 am, (Marc Espie) wrote:
In article , James Kanze wrote:
Pour commencer. Il faut bien aussi se retrouver dans un groupe de processus à soi (pour ne pas prendre des signaux destinés à un parent, par exemple), et normalement s'assurer aussi d'être orphlin (pour ne pas devenir zombie). Et d'être déconnecté du terminal.
C'est ce que fait le setsid() plus la fermeture des fd 0, 1, 2...
Oui, mais Merwin n'en avait pas parlé. Que de fork() et exit() dans le père.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Je regarderai de ce coté la, merci.
James Kanze a écrit :
On Mar 13, 10:48 am, es...@lain.home (Marc Espie) wrote:
In article
<556ec9f5-b305-4f33-b6ad-6411d673b...@h20g2000yqn.googlegroups.com>,
James Kanze <james.ka...@gmail.com> wrote:
Pour commencer. Il faut bien aussi se retrouver dans un
groupe de processus à soi (pour ne pas prendre des signaux
destinés à un parent, par exemple), et normalement s'assurer
aussi d'être orphlin (pour ne pas devenir zombie). Et d'être
déconnecté du terminal.
C'est ce que fait le setsid() plus la fermeture des fd 0, 1,
2...
Oui, mais Merwin n'en avait pas parlé. Que de fork() et exit()
dans le père.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Pour commencer. Il faut bien aussi se retrouver dans un groupe de processus à soi (pour ne pas prendre des signaux destinés à un parent, par exemple), et normalement s'assurer aussi d'être orphlin (pour ne pas devenir zombie). Et d'être déconnecté du terminal.
C'est ce que fait le setsid() plus la fermeture des fd 0, 1, 2...
Oui, mais Merwin n'en avait pas parlé. Que de fork() et exit() dans le père.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Je regarderai de ce coté la, merci.
Michael DOUBEZ
Ael Rowen Terence wrote:
"Michael DOUBEZ" a écrit dans le message de groupe de discussion : 49ba4fbb$0$3561$
Ael Rowen Terence wrote:
"Michael DOUBEZ" a écrit dans le message de groupe de discussion : 49ba2b12$0$24822$
James Kanze wrote:
Il est généralement possible de wrapper ces mécanisme dans des classes de façon à avoir les même interfaces osu Linux et Windows. Mais ça a été fait des millions de fois, je ne vois pas l'intérêt de travailler avec des notion bas niveau lorsque des bibliothèques sont disponibles.
Pour une meilleur compréhension.
Une meilleure compréhension de quoi ? Des mécanismes et détails d'implémentation spécifiques à un OS ?
Oui, entre autres. Qu'il y en est (je me compte parmi eux) pour qui réinventer la roue est une occasion de s'améliorer, n'a rien d'abscons.
Je ne nie pas la valeur pédagogique de refaire des choses connues (quicksort ou autres algorithmes non triviaux). Mais dans ce cas précis, j'en doute. Ce serait comme utiliser une API-C pour comprendre le wrapper C++.
Après, que la grande-grande-majorité pense que cela ne leur servirait à rien, c'est leur droit.
Ca m'est arrivé de ré-implémenter une stack TCP (simple) ainsi que d'autres protocoles et j'ai beaucoup appris mais ici ?
Chacun fait suivant sa sensibilité, et c'est bien ainsi. Pourquoi ce diktat : ne pas réécrire ... alors que ce qui nous entoure est renouvellement, même la roue des origines a été maintes fois réinventée.
Je proteste, la roue n'a été inventée qu'une seule fois. Ensuite ce sont des améliorations techniques.
Ensuite "pourquoi ne pas réécrire ?": comme tu le dis, chacun est libre de perdre son temps mais il y a certains avantages à utiliser une bibliothèque testée, pensée et raffinée par plusieurs centaines d'utilisateurs.
-- Michael
Ael Rowen Terence wrote:
"Michael DOUBEZ" <michael.doubez@free.fr> a écrit dans le message de
groupe de discussion : 49ba4fbb$0$3561$426a74cc@news.free.fr...
Ael Rowen Terence wrote:
"Michael DOUBEZ" <michael.doubez@free.fr> a écrit dans le message de
groupe de discussion : 49ba2b12$0$24822$426a74cc@news.free.fr...
James Kanze wrote:
Il est généralement possible de wrapper ces mécanisme dans des
classes de façon à avoir les même interfaces osu Linux et Windows.
Mais ça a été fait des millions de fois, je ne vois pas l'intérêt de
travailler avec des notion bas niveau lorsque des bibliothèques sont
disponibles.
Pour une meilleur compréhension.
Une meilleure compréhension de quoi ?
Des mécanismes et détails d'implémentation spécifiques à un OS ?
Oui, entre autres.
Qu'il y en est (je me compte parmi eux) pour qui réinventer la roue est
une occasion de s'améliorer, n'a rien d'abscons.
Je ne nie pas la valeur pédagogique de refaire des choses connues
(quicksort ou autres algorithmes non triviaux). Mais dans ce cas précis,
j'en doute. Ce serait comme utiliser une API-C pour comprendre le
wrapper C++.
Après, que la grande-grande-majorité pense que cela ne leur servirait à
rien, c'est leur droit.
Ca m'est arrivé de ré-implémenter une stack TCP (simple) ainsi que
d'autres protocoles et j'ai beaucoup appris mais ici ?
Chacun fait suivant sa sensibilité, et c'est bien ainsi.
Pourquoi ce diktat : ne pas réécrire ... alors que ce qui nous entoure
est renouvellement, même la roue des origines a été maintes fois
réinventée.
Je proteste, la roue n'a été inventée qu'une seule fois. Ensuite ce sont
des améliorations techniques.
Ensuite "pourquoi ne pas réécrire ?": comme tu le dis, chacun est libre
de perdre son temps mais il y a certains avantages à utiliser une
bibliothèque testée, pensée et raffinée par plusieurs centaines
d'utilisateurs.
"Michael DOUBEZ" a écrit dans le message de groupe de discussion : 49ba4fbb$0$3561$
Ael Rowen Terence wrote:
"Michael DOUBEZ" a écrit dans le message de groupe de discussion : 49ba2b12$0$24822$
James Kanze wrote:
Il est généralement possible de wrapper ces mécanisme dans des classes de façon à avoir les même interfaces osu Linux et Windows. Mais ça a été fait des millions de fois, je ne vois pas l'intérêt de travailler avec des notion bas niveau lorsque des bibliothèques sont disponibles.
Pour une meilleur compréhension.
Une meilleure compréhension de quoi ? Des mécanismes et détails d'implémentation spécifiques à un OS ?
Oui, entre autres. Qu'il y en est (je me compte parmi eux) pour qui réinventer la roue est une occasion de s'améliorer, n'a rien d'abscons.
Je ne nie pas la valeur pédagogique de refaire des choses connues (quicksort ou autres algorithmes non triviaux). Mais dans ce cas précis, j'en doute. Ce serait comme utiliser une API-C pour comprendre le wrapper C++.
Après, que la grande-grande-majorité pense que cela ne leur servirait à rien, c'est leur droit.
Ca m'est arrivé de ré-implémenter une stack TCP (simple) ainsi que d'autres protocoles et j'ai beaucoup appris mais ici ?
Chacun fait suivant sa sensibilité, et c'est bien ainsi. Pourquoi ce diktat : ne pas réécrire ... alors que ce qui nous entoure est renouvellement, même la roue des origines a été maintes fois réinventée.
Je proteste, la roue n'a été inventée qu'une seule fois. Ensuite ce sont des améliorations techniques.
Ensuite "pourquoi ne pas réécrire ?": comme tu le dis, chacun est libre de perdre son temps mais il y a certains avantages à utiliser une bibliothèque testée, pensée et raffinée par plusieurs centaines d'utilisateurs.
-- Michael
Jean-Marc Bourguet
Michael DOUBEZ writes:
Ael Rowen Terence wrote:
Chacun fait suivant sa sensibilité, et c'est bien ainsi. Pourquoi ce diktat : ne pas réécrire ... alors que ce qui nous entoure est renouvellement, même la roue des origines a été maintes fois réinventée.
Je proteste, la roue n'a été inventée qu'une seule fois. Ensuite ce sont des améliorations techniques.
Est-ce qu'il y en a un de vous deux qui peut apporter un commencement de preuve?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Michael DOUBEZ <michael.doubez@free.fr> writes:
Ael Rowen Terence wrote:
Chacun fait suivant sa sensibilité, et c'est bien ainsi. Pourquoi ce
diktat : ne pas réécrire ... alors que ce qui nous entoure est
renouvellement, même la roue des origines a été maintes fois réinventée.
Je proteste, la roue n'a été inventée qu'une seule fois. Ensuite ce sont
des améliorations techniques.
Est-ce qu'il y en a un de vous deux qui peut apporter un commencement de
preuve?
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Chacun fait suivant sa sensibilité, et c'est bien ainsi. Pourquoi ce diktat : ne pas réécrire ... alors que ce qui nous entoure est renouvellement, même la roue des origines a été maintes fois réinventée.
Je proteste, la roue n'a été inventée qu'une seule fois. Ensuite ce sont des améliorations techniques.
Est-ce qu'il y en a un de vous deux qui peut apporter un commencement de preuve?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Marc Boyer
On 2009-03-13, Ael Rowen Terence wrote:
"Michael DOUBEZ" a écrit dans le message de groupe de discussion : 49ba4fbb$0$3561$
Ael Rowen Terence wrote:
"Michael DOUBEZ" a écrit dans le message de groupe de discussion : 49ba2b12$0$24822$
Il est généralement possible de wrapper ces mécanisme dans des classes de façon à avoir les même interfaces osu Linux et Windows. Mais ça a été fait des millions de fois, je ne vois pas l'intérêt de travailler avec des notion bas niveau lorsque des bibliothèques sont disponibles.
Pour une meilleur compréhension.
Une meilleure compréhension de quoi ? Des mécanismes et détails d'implémentation spécifiques à un OS ?
Oui, entre autres. Qu'il y en est (je me compte parmi eux) pour qui réinventer la roue est une occasion de s'améliorer, n'a rien d'abscons. Après, que la grande-grande-majorité pense que cela ne leur servirait à rien, c'est leur droit. Chacun fait suivant sa sensibilité, et c'est bien ainsi.
Les dillétantes, amateurs et free-lance font selon leurs envies. Les salariés sont payés généralement pour écrire du code robuste, maintenable et pour faire ça vite en plus.
Pourquoi ce diktat : ne pas réécrire ... alors que ce qui nous entoure est renouvellement, même la roue des origines a été maintes fois réinventée.
Parce que le truc que tu vas faire sera très surement moins bien que l'existant, et que si ton but c'est d'apprendre les différences entre les deux, il y a des moyens plus efficaces.
Marc Boyer -- Au XXIème siècle, notre projet de société s'est réduit à un projet économique...
On 2009-03-13, Ael Rowen Terence <Sans.Reponse@mail.fr> wrote:
"Michael DOUBEZ" <michael.doubez@free.fr> a écrit dans le message de groupe
de discussion : 49ba4fbb$0$3561$426a74cc@news.free.fr...
Ael Rowen Terence wrote:
"Michael DOUBEZ" <michael.doubez@free.fr> a écrit dans le message de
groupe de discussion : 49ba2b12$0$24822$426a74cc@news.free.fr...
Il est généralement possible de wrapper ces mécanisme dans des classes
de façon à avoir les même interfaces osu Linux et Windows. Mais ça a été
fait des millions de fois, je ne vois pas l'intérêt de travailler avec
des notion bas niveau lorsque des bibliothèques sont disponibles.
Pour une meilleur compréhension.
Une meilleure compréhension de quoi ?
Des mécanismes et détails d'implémentation spécifiques à un OS ?
Oui, entre autres.
Qu'il y en est (je me compte parmi eux) pour qui réinventer la roue est une
occasion de s'améliorer, n'a rien d'abscons.
Après, que la grande-grande-majorité pense que cela ne leur servirait à
rien, c'est leur droit.
Chacun fait suivant sa sensibilité, et c'est bien ainsi.
Les dillétantes, amateurs et free-lance font selon leurs envies.
Les salariés sont payés généralement pour écrire du code robuste,
maintenable et pour faire ça vite en plus.
Pourquoi ce diktat : ne pas réécrire ... alors que ce qui nous entoure est
renouvellement, même la roue des origines a été maintes fois réinventée.
Parce que le truc que tu vas faire sera très surement moins bien que
l'existant, et que si ton but c'est d'apprendre les différences entre
les deux, il y a des moyens plus efficaces.
Marc Boyer
--
Au XXIème siècle, notre projet de société s'est réduit
à un projet économique...
"Michael DOUBEZ" a écrit dans le message de groupe de discussion : 49ba4fbb$0$3561$
Ael Rowen Terence wrote:
"Michael DOUBEZ" a écrit dans le message de groupe de discussion : 49ba2b12$0$24822$
Il est généralement possible de wrapper ces mécanisme dans des classes de façon à avoir les même interfaces osu Linux et Windows. Mais ça a été fait des millions de fois, je ne vois pas l'intérêt de travailler avec des notion bas niveau lorsque des bibliothèques sont disponibles.
Pour une meilleur compréhension.
Une meilleure compréhension de quoi ? Des mécanismes et détails d'implémentation spécifiques à un OS ?
Oui, entre autres. Qu'il y en est (je me compte parmi eux) pour qui réinventer la roue est une occasion de s'améliorer, n'a rien d'abscons. Après, que la grande-grande-majorité pense que cela ne leur servirait à rien, c'est leur droit. Chacun fait suivant sa sensibilité, et c'est bien ainsi.
Les dillétantes, amateurs et free-lance font selon leurs envies. Les salariés sont payés généralement pour écrire du code robuste, maintenable et pour faire ça vite en plus.
Pourquoi ce diktat : ne pas réécrire ... alors que ce qui nous entoure est renouvellement, même la roue des origines a été maintes fois réinventée.
Parce que le truc que tu vas faire sera très surement moins bien que l'existant, et que si ton but c'est d'apprendre les différences entre les deux, il y a des moyens plus efficaces.
Marc Boyer -- Au XXIème siècle, notre projet de société s'est réduit à un projet économique...
Ael Rowen Terence
"Marc Boyer" a écrit dans le message de groupe de discussion :
On 2009-03-13, Ael Rowen Terence wrote:
"Michael DOUBEZ" a écrit dans le message de groupe de discussion : 49ba4fbb$0$3561$
Ael Rowen Terence wrote:
"Michael DOUBEZ" a écrit dans le message de groupe de discussion : 49ba2b12$0$24822$
Il est généralement possible de wrapper ces mécanisme dans des classes de façon à avoir les même interfaces ossu Linux et Windows. Mais ça a été fait des millions de fois, je ne vois pas l'intérêt de travailler avec des notion bas niveau lorsque des bibliothèques sont disponibles.
Pour une meilleur compréhension.
Une meilleure compréhension de quoi ? Des mécanismes et détails d'implémentation spécifiques à un OS ?
Oui, entre autres. Qu'il y en est (je me compte parmi eux) pour qui réinventer la roue est une occasion de s'améliorer, n'a rien d'abscons. Après, que la grande-grande-majorité pense que cela ne leur servirait à rien, c'est leur droit. Chacun fait suivant sa sensibilité, et c'est bien ainsi.
Les dillétantes, amateurs et free-lance font selon leurs envies. Les salariés sont payés généralement pour écrire du code robuste, maintenable et pour faire ça vite en plus.
Pourquoi ce diktat : ne pas réécrire ... alors que ce qui nous entoure est renouvellement, même la roue des origines a été maintes fois réinventée.
Parce que le truc que tu vas faire sera très surement moins bien que l'existant, et que si ton but c'est d'apprendre les différences entre les deux, il y a des moyens plus efficaces.
Pourrais-tu en dire plus sur ces moyens ?
"Marc Boyer" <Marc.Boyer@cert.onera.fr.invalid> a écrit dans le message de
groupe de discussion : slrngrs74b.fcb.Marc.Boyer@gavarnie.cert.fr...
On 2009-03-13, Ael Rowen Terence <Sans.Reponse@mail.fr> wrote:
"Michael DOUBEZ" <michael.doubez@free.fr> a écrit dans le message de
groupe
de discussion : 49ba4fbb$0$3561$426a74cc@news.free.fr...
Ael Rowen Terence wrote:
"Michael DOUBEZ" <michael.doubez@free.fr> a écrit dans le message de
groupe de discussion : 49ba2b12$0$24822$426a74cc@news.free.fr...
Il est généralement possible de wrapper ces mécanisme dans des classes
de façon à avoir les même interfaces ossu Linux et Windows. Mais ça a
été
fait des millions de fois, je ne vois pas l'intérêt de travailler avec
des notion bas niveau lorsque des bibliothèques sont disponibles.
Pour une meilleur compréhension.
Une meilleure compréhension de quoi ?
Des mécanismes et détails d'implémentation spécifiques à un OS ?
Oui, entre autres.
Qu'il y en est (je me compte parmi eux) pour qui réinventer la roue est
une
occasion de s'améliorer, n'a rien d'abscons.
Après, que la grande-grande-majorité pense que cela ne leur servirait à
rien, c'est leur droit.
Chacun fait suivant sa sensibilité, et c'est bien ainsi.
Les dillétantes, amateurs et free-lance font selon leurs envies.
Les salariés sont payés généralement pour écrire du code robuste,
maintenable et pour faire ça vite en plus.
Pourquoi ce diktat : ne pas réécrire ... alors que ce qui nous entoure
est
renouvellement, même la roue des origines a été maintes fois réinventée.
Parce que le truc que tu vas faire sera très surement moins bien que
l'existant, et que si ton but c'est d'apprendre les différences entre
les deux, il y a des moyens plus efficaces.
"Marc Boyer" a écrit dans le message de groupe de discussion :
On 2009-03-13, Ael Rowen Terence wrote:
"Michael DOUBEZ" a écrit dans le message de groupe de discussion : 49ba4fbb$0$3561$
Ael Rowen Terence wrote:
"Michael DOUBEZ" a écrit dans le message de groupe de discussion : 49ba2b12$0$24822$
Il est généralement possible de wrapper ces mécanisme dans des classes de façon à avoir les même interfaces ossu Linux et Windows. Mais ça a été fait des millions de fois, je ne vois pas l'intérêt de travailler avec des notion bas niveau lorsque des bibliothèques sont disponibles.
Pour une meilleur compréhension.
Une meilleure compréhension de quoi ? Des mécanismes et détails d'implémentation spécifiques à un OS ?
Oui, entre autres. Qu'il y en est (je me compte parmi eux) pour qui réinventer la roue est une occasion de s'améliorer, n'a rien d'abscons. Après, que la grande-grande-majorité pense que cela ne leur servirait à rien, c'est leur droit. Chacun fait suivant sa sensibilité, et c'est bien ainsi.
Les dillétantes, amateurs et free-lance font selon leurs envies. Les salariés sont payés généralement pour écrire du code robuste, maintenable et pour faire ça vite en plus.
Pourquoi ce diktat : ne pas réécrire ... alors que ce qui nous entoure est renouvellement, même la roue des origines a été maintes fois réinventée.
Parce que le truc que tu vas faire sera très surement moins bien que l'existant, et que si ton but c'est d'apprendre les différences entre les deux, il y a des moyens plus efficaces.
