je viens d'installer Mandriva 2007 sur un portable acer TM230
Probleme :
le systeme arrete pour un soucis de temperature critique 77°
Bon je fais un tour sur google et je vois qu'il faut faire un acpi=off
au boot.
Mais là un autre probleme apparait : Kernel Panic
Bon ben je me dis que la migration vers linux commence bien :o(
Reviens quand tu sauras de quoi tu parles. c'est pas moi qui annonce que les casts sont ...
comment tu dis ah oui moins fiables
moi je dis juste que c'est un pouhieme plus lent
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception la preuve http://remyaumeunier.chez-alice.fr/ remy
Nicolas George
remy , dans le message <enj1vs$e8g$, a écrit :
ou qu'il y a une structure specifique a un type
Non, il n'y en a pas, justement.
c'est pas moi qui annonce que les casts sont ... comment tu dis ah oui moins fiables
Ça l'est. Tu n'étais pas au courant ? Un cast, ça peut lever une ClassCastException. Potentiellement après que ton programme a tourné pendant une semaine pour te trouver un résultat.
remy , dans le message <enj1vs$e8g$1@s1.news.oleane.net>, a écrit :
ou qu'il y a une structure specifique a un type
Non, il n'y en a pas, justement.
c'est pas moi qui annonce que les casts sont ...
comment tu dis ah oui moins fiables
Ça l'est. Tu n'étais pas au courant ? Un cast, ça peut lever une
ClassCastException. Potentiellement après que ton programme a tourné pendant
une semaine pour te trouver un résultat.
c'est pas moi qui annonce que les casts sont ... comment tu dis ah oui moins fiables
Ça l'est. Tu n'étais pas au courant ? Un cast, ça peut lever une ClassCastException. Potentiellement après que ton programme a tourné pendant une semaine pour te trouver un résultat.
talon
Nicolas George <nicolas$ wrote:
Michel Talon, dans le message <enivg0$1n1o$, a écrit :
Je suis d'accord avec ce que tu dis, encore plus avec l'automaticité.
Ah, alors pourquoi dis-tu exactement le contraire juste en dessous ?
Je ne dis pas le contraire ci-dessous, je pense à la situation du C++ et de la syntaxe et complexité phénoménales qu'il faut introduire avec les templates pour résoudre ce problème.
En fait , à mon avis, toutes ces vérifications à la compilation sont totalement inutiles, et n'ont jamais garanti la correction d'un programme.
Ce n'est pas parfait donc ça ne sert à rien ? C'est bancal, comme position.
Non, le problème est que ça a un coût trés élevé pour un bénéfice minime, à mon avis.
Détecter les erreurs de type à la compilation sans syntaxe, ça se fait très bien.
C'est possible, je ne suis pas un spécialiste comme toi, mais il faut croire que ce n'est pas trés utilisé en pratique, vu que C++, C# et Java introduisent une syntaxe spécifique. D'aprés ce que j'ai cru comprendre, la différence entre les génériques dans C# et dans Java, c'est justement que dans C# les types sont découverts à la première exécution, et ensuite vérifiés dans les exécutions ultérieures. En python il n'y a aucune déclaration de type, les types sont découverts dynamiquement. Si on écrit 1+"1" on ne va pas récolter 2, mais une exception, ce qui est le seul comportement sain, par opposition aux comportements à la graisse de phoque style perl ou des conversions automatiques sont effectuées "en fonction du contexte". Par contre, quelle est l'utilité de savoir qu'une liste est une liste d'entiers ou une liste de strings? Cette utilité est parfaitement nulle, en python on peut très bien mettre les deux dans la même liste, comme [1,"a",2,"b"]. Les templates ou leurs versions affadies servent à résoudre un faux problème.
et d'offrir au moins autant de garanties de correction du programme.
Non, les garanties ne sont pas aussi fortes. Plus exactement, la détection à la compilation trouve les erreurs plus tôt. Imagine un programme qui vient de faire un calcul pendant dix minutes / deux heures / deux semaines, et qui se plante au moment d'afficher le résultat parce qu'on a mis une variable à la place d'une autre. Eh bien si le problème est une erreur de type, alors un outil qui fait la vérification à la compilation t'aurait fait gagner dix minutes / deux heures / deux semaines. Tu trouves que ça ne vaut pas le coût ?
C'est exact, ça m'est même arrivé. Cependant si on teste son programme petit bout par petit bout, la différence entre ça et découvrir des erreurs à la compilation n'est pas trés grande.
Sans compter, évidemment, que quand la vérification de type est faite à la compilation, certaines optimisations deviennent possibles qui peuvent faire gagner une vitesse considérable
Surtout quand l'optimisation est effectuée "just in time" sur du code en cours d'exécution comme dans Java?
--
Michel TALON
Nicolas George <nicolas$george@salle-s.org> wrote:
Michel Talon, dans le message <enivg0$1n1o$1@asmodee.lpthe.jussieu.fr>,
a écrit :
Je suis d'accord avec ce que tu dis, encore plus avec l'automaticité.
Ah, alors pourquoi dis-tu exactement le contraire juste en dessous ?
Je ne dis pas le contraire ci-dessous, je pense à la situation du C++ et
de la syntaxe et complexité phénoménales qu'il faut introduire avec les
templates pour résoudre ce problème.
En fait , à mon avis, toutes ces vérifications à la compilation sont
totalement inutiles, et n'ont jamais garanti la correction d'un
programme.
Ce n'est pas parfait donc ça ne sert à rien ? C'est bancal, comme position.
Non, le problème est que ça a un coût trés élevé pour un bénéfice
minime, à mon avis.
Détecter les erreurs de type à la compilation sans syntaxe, ça se fait très
bien.
C'est possible, je ne suis pas un spécialiste comme toi, mais il faut
croire que ce n'est pas trés utilisé en pratique, vu que C++, C# et Java
introduisent une syntaxe spécifique. D'aprés ce que j'ai cru comprendre,
la différence entre les génériques dans C# et dans Java, c'est justement
que dans C# les types sont découverts à la première exécution, et
ensuite vérifiés dans les exécutions ultérieures. En python il n'y a
aucune déclaration de type, les types sont découverts dynamiquement.
Si on écrit 1+"1" on ne va pas récolter 2, mais une exception, ce qui
est le seul comportement sain, par opposition aux comportements à la
graisse de phoque style perl ou des conversions automatiques sont
effectuées "en fonction du contexte". Par contre, quelle est l'utilité
de savoir qu'une liste est une liste d'entiers ou une liste de strings?
Cette utilité est parfaitement nulle, en python on peut très bien mettre
les deux dans la même liste, comme [1,"a",2,"b"]. Les templates ou leurs
versions affadies servent à résoudre un faux problème.
et d'offrir au moins
autant de garanties de correction du programme.
Non, les garanties ne sont pas aussi fortes. Plus exactement, la détection à
la compilation trouve les erreurs plus tôt. Imagine un programme qui vient
de faire un calcul pendant dix minutes / deux heures / deux semaines, et qui
se plante au moment d'afficher le résultat parce qu'on a mis une variable à
la place d'une autre. Eh bien si le problème est une erreur de type, alors
un outil qui fait la vérification à la compilation t'aurait fait gagner dix
minutes / deux heures / deux semaines. Tu trouves que ça ne vaut pas le
coût ?
C'est exact, ça m'est même arrivé. Cependant si on teste son programme
petit bout par petit bout, la différence entre ça et découvrir des
erreurs à la compilation n'est pas trés grande.
Sans compter, évidemment, que quand la vérification de type est faite à la
compilation, certaines optimisations deviennent possibles qui peuvent faire
gagner une vitesse considérable
Surtout quand l'optimisation est effectuée "just in time" sur du code en
cours d'exécution comme dans Java?
Michel Talon, dans le message <enivg0$1n1o$, a écrit :
Je suis d'accord avec ce que tu dis, encore plus avec l'automaticité.
Ah, alors pourquoi dis-tu exactement le contraire juste en dessous ?
Je ne dis pas le contraire ci-dessous, je pense à la situation du C++ et de la syntaxe et complexité phénoménales qu'il faut introduire avec les templates pour résoudre ce problème.
En fait , à mon avis, toutes ces vérifications à la compilation sont totalement inutiles, et n'ont jamais garanti la correction d'un programme.
Ce n'est pas parfait donc ça ne sert à rien ? C'est bancal, comme position.
Non, le problème est que ça a un coût trés élevé pour un bénéfice minime, à mon avis.
Détecter les erreurs de type à la compilation sans syntaxe, ça se fait très bien.
C'est possible, je ne suis pas un spécialiste comme toi, mais il faut croire que ce n'est pas trés utilisé en pratique, vu que C++, C# et Java introduisent une syntaxe spécifique. D'aprés ce que j'ai cru comprendre, la différence entre les génériques dans C# et dans Java, c'est justement que dans C# les types sont découverts à la première exécution, et ensuite vérifiés dans les exécutions ultérieures. En python il n'y a aucune déclaration de type, les types sont découverts dynamiquement. Si on écrit 1+"1" on ne va pas récolter 2, mais une exception, ce qui est le seul comportement sain, par opposition aux comportements à la graisse de phoque style perl ou des conversions automatiques sont effectuées "en fonction du contexte". Par contre, quelle est l'utilité de savoir qu'une liste est une liste d'entiers ou une liste de strings? Cette utilité est parfaitement nulle, en python on peut très bien mettre les deux dans la même liste, comme [1,"a",2,"b"]. Les templates ou leurs versions affadies servent à résoudre un faux problème.
et d'offrir au moins autant de garanties de correction du programme.
Non, les garanties ne sont pas aussi fortes. Plus exactement, la détection à la compilation trouve les erreurs plus tôt. Imagine un programme qui vient de faire un calcul pendant dix minutes / deux heures / deux semaines, et qui se plante au moment d'afficher le résultat parce qu'on a mis une variable à la place d'une autre. Eh bien si le problème est une erreur de type, alors un outil qui fait la vérification à la compilation t'aurait fait gagner dix minutes / deux heures / deux semaines. Tu trouves que ça ne vaut pas le coût ?
C'est exact, ça m'est même arrivé. Cependant si on teste son programme petit bout par petit bout, la différence entre ça et découvrir des erreurs à la compilation n'est pas trés grande.
Sans compter, évidemment, que quand la vérification de type est faite à la compilation, certaines optimisations deviennent possibles qui peuvent faire gagner une vitesse considérable
Surtout quand l'optimisation est effectuée "just in time" sur du code en cours d'exécution comme dans Java?
--
Michel TALON
remy
ou qu'il y a une structure specifique a un type
Non, il n'y en a pas, justement.
bon alors mets un vecteur dans l'obj si tu veux moi, tu sais je ne suis pas contrariant
c'est pas moi qui annonce que les casts sont ... comment tu dis ah oui moins fiables
Ça l'est. Tu n'étais pas au courant ? Un cast, ça peut lever une ClassCastException. Potentiellement après que ton programme a tourné pendant une semaine pour te trouver un résultat.
surement mais chez moi les poules ne font que de maniere tres exceptionnelle des chevaux et qd cela arrive cela s'appelle une erreur ou un bug
mais tu sais ...
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception la preuve http://remyaumeunier.chez-alice.fr/ remy
ou qu'il y a une structure specifique a un type
Non, il n'y en a pas, justement.
bon alors mets un vecteur dans l'obj si tu veux
moi, tu sais je ne suis pas contrariant
c'est pas moi qui annonce que les casts sont ...
comment tu dis ah oui moins fiables
Ça l'est. Tu n'étais pas au courant ? Un cast, ça peut lever une
ClassCastException. Potentiellement après que ton programme a tourné pendant
une semaine pour te trouver un résultat.
surement mais chez moi les poules ne font que de maniere tres
exceptionnelle des chevaux
et qd cela arrive cela s'appelle une erreur ou un bug
mais tu sais ...
--
des conneries j'en ai dites oui oui je vous assure...
mais elles n'engagent que votre perception
la preuve http://remyaumeunier.chez-alice.fr/
remy
bon alors mets un vecteur dans l'obj si tu veux moi, tu sais je ne suis pas contrariant
c'est pas moi qui annonce que les casts sont ... comment tu dis ah oui moins fiables
Ça l'est. Tu n'étais pas au courant ? Un cast, ça peut lever une ClassCastException. Potentiellement après que ton programme a tourné pendant une semaine pour te trouver un résultat.
surement mais chez moi les poules ne font que de maniere tres exceptionnelle des chevaux et qd cela arrive cela s'appelle une erreur ou un bug
mais tu sais ...
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception la preuve http://remyaumeunier.chez-alice.fr/ remy
Nicolas George
Michel Talon, dans le message <enj2of$1nrs$, a écrit :
Je ne dis pas le contraire ci-dessous, je pense à la situation du C++ et de la syntaxe et complexité phénoménales qu'il faut introduire avec les templates pour résoudre ce problème.
Évidemment. Je ne parlais pas du c++. Le c++ est une merde infâme, nous sommes d'accord. Mais le c++ est merdique parce qu'il est mal conçu, avec des objectifs bâtards, pas parce que les concepts qu'il cherche à implémenter sont fondamentalement mauvais.
Non, le problème est que ça a un coût trés élevé pour un bénéfice minime, à mon avis.
Je pense que tu dis ça parce que tu n'as pas assez pratiqué de langage qui fasse les choses de manière pratique.
C'est possible, je ne suis pas un spécialiste comme toi, mais il faut
Je ne suis pas particulièrement spécialiste, hein.
croire que ce n'est pas trés utilisé en pratique, vu que C++, C# et Java introduisent une syntaxe spécifique. D'aprés ce que j'ai cru comprendre, la différence entre les génériques dans C# et dans Java,
Parce que ça dérouterait les pisseurs de code.
c'est justement que dans C# les types sont découverts à la première exécution,
C'est une première étape. L'étape suivante, c'est de découvrir les types à la première utilisation de l'objet non pas à l'exécution, mais simplement dans le code du programme.
Typiquement, si le compilateur voit quelque part :
l.add(s);
alors que s est une chaîne de caractères, alors il sait que l est une liste de chaînes de caractères, et peut faire la vérification partout ailleurs.
En python il n'y a aucune déclaration de type, les types sont découverts dynamiquement. Si on écrit 1+"1" on ne va pas récolter 2, mais une exception, ce qui est le seul comportement sain,
Je ne suis pas d'accord : le seul comportement sain est que le programme ne commence même pas à s'exécuter, parce qu'on _sait_ dès le début qu'il va y avoir une erreur.
Par contre, quelle est l'utilité de savoir qu'une liste est une liste d'entiers ou une liste de strings? Cette utilité est parfaitement nulle,
Ça permet de détecter des erreurs plus tôt, et donc quand elles sont moins coûteuses et pénibles à corriger. Si tu as une liste qui est censée, dans la logique de ton programme, contenir des points de l'espace (donc un objet à trois coordonnées), et que tu te rends compte à un endroit du programme qu'il y a un réel qui se balade dans cette liste, tu vas devoir chercher où diable tu as pu insérer un réel là où tu voulais insérer un point. Si le compilateur connaît le type des objets, il te le dit : « attention, en ligne 42, vous avez une liste de vecteurs, si vous essayez d'y ajouter un entier, ça va chier ».
en python on peut très bien mettre les deux dans la même liste, comme [1,"a",2,"b"].
Oui, on _peut_, mais est-ce utile ? Pourrais-tu citer des cas où il est souhaitable qu'une liste (utilisée en tant que liste, pas en tant que remplacement pour une structure) contienne des objets de type incompatibles ? Le principe d'une liste, c'est d'avoir une collection d'objets qui suivent un même traitement ; par définition, ça ne peut servir que si les objets peuvent subir le même traitement.
C'est exact, ça m'est même arrivé. Cependant si on teste son programme petit bout par petit bout, la différence entre ça et découvrir des erreurs à la compilation n'est pas trés grande.
Il y a une différence fondamentale : les tests dont tu parles, ils sont faits à la main, et à ce titre, sujets à une erreur humaine : tu peux toujours oublier de tester un des cas rare de ton programme, et Murphy aidant, ce sera précisément le cas où il y a un problème.
Une vérification, de type ou autre, faite automatiquement l'est de manière absolument systématique, sans oubli.
Surtout quand l'optimisation est effectuée "just in time" sur du code en cours d'exécution comme dans Java?
Un peu moins, certes, mais quand même.
Michel Talon, dans le message <enj2of$1nrs$1@asmodee.lpthe.jussieu.fr>,
a écrit :
Je ne dis pas le contraire ci-dessous, je pense à la situation du C++ et
de la syntaxe et complexité phénoménales qu'il faut introduire avec les
templates pour résoudre ce problème.
Évidemment. Je ne parlais pas du c++. Le c++ est une merde infâme, nous
sommes d'accord. Mais le c++ est merdique parce qu'il est mal conçu, avec
des objectifs bâtards, pas parce que les concepts qu'il cherche à
implémenter sont fondamentalement mauvais.
Non, le problème est que ça a un coût trés élevé pour un bénéfice
minime, à mon avis.
Je pense que tu dis ça parce que tu n'as pas assez pratiqué de langage qui
fasse les choses de manière pratique.
C'est possible, je ne suis pas un spécialiste comme toi, mais il faut
Je ne suis pas particulièrement spécialiste, hein.
croire que ce n'est pas trés utilisé en pratique, vu que C++, C# et Java
introduisent une syntaxe spécifique. D'aprés ce que j'ai cru comprendre,
la différence entre les génériques dans C# et dans Java,
Parce que ça dérouterait les pisseurs de code.
c'est justement
que dans C# les types sont découverts à la première exécution,
C'est une première étape. L'étape suivante, c'est de découvrir les types à
la première utilisation de l'objet non pas à l'exécution, mais simplement
dans le code du programme.
Typiquement, si le compilateur voit quelque part :
l.add(s);
alors que s est une chaîne de caractères, alors il sait que l est une liste
de chaînes de caractères, et peut faire la vérification partout ailleurs.
En python il n'y a
aucune déclaration de type, les types sont découverts dynamiquement.
Si on écrit 1+"1" on ne va pas récolter 2, mais une exception, ce qui
est le seul comportement sain,
Je ne suis pas d'accord : le seul comportement sain est que le programme ne
commence même pas à s'exécuter, parce qu'on _sait_ dès le début qu'il va y
avoir une erreur.
Par contre, quelle est l'utilité
de savoir qu'une liste est une liste d'entiers ou une liste de strings?
Cette utilité est parfaitement nulle,
Ça permet de détecter des erreurs plus tôt, et donc quand elles sont moins
coûteuses et pénibles à corriger. Si tu as une liste qui est censée, dans la
logique de ton programme, contenir des points de l'espace (donc un objet à
trois coordonnées), et que tu te rends compte à un endroit du programme
qu'il y a un réel qui se balade dans cette liste, tu vas devoir chercher où
diable tu as pu insérer un réel là où tu voulais insérer un point. Si le
compilateur connaît le type des objets, il te le dit : « attention, en ligne
42, vous avez une liste de vecteurs, si vous essayez d'y ajouter un entier,
ça va chier ».
en python on peut très bien mettre
les deux dans la même liste, comme [1,"a",2,"b"].
Oui, on _peut_, mais est-ce utile ? Pourrais-tu citer des cas où il est
souhaitable qu'une liste (utilisée en tant que liste, pas en tant que
remplacement pour une structure) contienne des objets de type
incompatibles ? Le principe d'une liste, c'est d'avoir une collection
d'objets qui suivent un même traitement ; par définition, ça ne peut servir
que si les objets peuvent subir le même traitement.
C'est exact, ça m'est même arrivé. Cependant si on teste son programme
petit bout par petit bout, la différence entre ça et découvrir des
erreurs à la compilation n'est pas trés grande.
Il y a une différence fondamentale : les tests dont tu parles, ils sont
faits à la main, et à ce titre, sujets à une erreur humaine : tu peux
toujours oublier de tester un des cas rare de ton programme, et Murphy
aidant, ce sera précisément le cas où il y a un problème.
Une vérification, de type ou autre, faite automatiquement l'est de manière
absolument systématique, sans oubli.
Surtout quand l'optimisation est effectuée "just in time" sur du code en
cours d'exécution comme dans Java?
Michel Talon, dans le message <enj2of$1nrs$, a écrit :
Je ne dis pas le contraire ci-dessous, je pense à la situation du C++ et de la syntaxe et complexité phénoménales qu'il faut introduire avec les templates pour résoudre ce problème.
Évidemment. Je ne parlais pas du c++. Le c++ est une merde infâme, nous sommes d'accord. Mais le c++ est merdique parce qu'il est mal conçu, avec des objectifs bâtards, pas parce que les concepts qu'il cherche à implémenter sont fondamentalement mauvais.
Non, le problème est que ça a un coût trés élevé pour un bénéfice minime, à mon avis.
Je pense que tu dis ça parce que tu n'as pas assez pratiqué de langage qui fasse les choses de manière pratique.
C'est possible, je ne suis pas un spécialiste comme toi, mais il faut
Je ne suis pas particulièrement spécialiste, hein.
croire que ce n'est pas trés utilisé en pratique, vu que C++, C# et Java introduisent une syntaxe spécifique. D'aprés ce que j'ai cru comprendre, la différence entre les génériques dans C# et dans Java,
Parce que ça dérouterait les pisseurs de code.
c'est justement que dans C# les types sont découverts à la première exécution,
C'est une première étape. L'étape suivante, c'est de découvrir les types à la première utilisation de l'objet non pas à l'exécution, mais simplement dans le code du programme.
Typiquement, si le compilateur voit quelque part :
l.add(s);
alors que s est une chaîne de caractères, alors il sait que l est une liste de chaînes de caractères, et peut faire la vérification partout ailleurs.
En python il n'y a aucune déclaration de type, les types sont découverts dynamiquement. Si on écrit 1+"1" on ne va pas récolter 2, mais une exception, ce qui est le seul comportement sain,
Je ne suis pas d'accord : le seul comportement sain est que le programme ne commence même pas à s'exécuter, parce qu'on _sait_ dès le début qu'il va y avoir une erreur.
Par contre, quelle est l'utilité de savoir qu'une liste est une liste d'entiers ou une liste de strings? Cette utilité est parfaitement nulle,
Ça permet de détecter des erreurs plus tôt, et donc quand elles sont moins coûteuses et pénibles à corriger. Si tu as une liste qui est censée, dans la logique de ton programme, contenir des points de l'espace (donc un objet à trois coordonnées), et que tu te rends compte à un endroit du programme qu'il y a un réel qui se balade dans cette liste, tu vas devoir chercher où diable tu as pu insérer un réel là où tu voulais insérer un point. Si le compilateur connaît le type des objets, il te le dit : « attention, en ligne 42, vous avez une liste de vecteurs, si vous essayez d'y ajouter un entier, ça va chier ».
en python on peut très bien mettre les deux dans la même liste, comme [1,"a",2,"b"].
Oui, on _peut_, mais est-ce utile ? Pourrais-tu citer des cas où il est souhaitable qu'une liste (utilisée en tant que liste, pas en tant que remplacement pour une structure) contienne des objets de type incompatibles ? Le principe d'une liste, c'est d'avoir une collection d'objets qui suivent un même traitement ; par définition, ça ne peut servir que si les objets peuvent subir le même traitement.
C'est exact, ça m'est même arrivé. Cependant si on teste son programme petit bout par petit bout, la différence entre ça et découvrir des erreurs à la compilation n'est pas trés grande.
Il y a une différence fondamentale : les tests dont tu parles, ils sont faits à la main, et à ce titre, sujets à une erreur humaine : tu peux toujours oublier de tester un des cas rare de ton programme, et Murphy aidant, ce sera précisément le cas où il y a un problème.
Une vérification, de type ou autre, faite automatiquement l'est de manière absolument systématique, sans oubli.
Surtout quand l'optimisation est effectuée "just in time" sur du code en cours d'exécution comme dans Java?
Un peu moins, certes, mais quand même.
Nicolas George
remy , dans le message <enj3ui$f61$, a écrit :
bon alors mets un vecteur dans l'obj si tu veux moi, tu sais je ne suis pas contrariant
Tu peux mettre tout ce que tu veux dedans, tu n'auras ni casts ni structures différentes. C'est précisément à ça que servent les génériques.
surement mais chez moi les poules ne font que de maniere tres exceptionnelle des chevaux et qd cela arrive cela s'appelle une erreur ou un bug
Oui, précisément, un bug. Les génériques, ça sert à détecter automatiquement plus de bugs.
On voit que tu sais ce dont tu parles, tiens...
remy , dans le message <enj3ui$f61$1@s1.news.oleane.net>, a écrit :
bon alors mets un vecteur dans l'obj si tu veux
moi, tu sais je ne suis pas contrariant
Tu peux mettre tout ce que tu veux dedans, tu n'auras ni casts ni structures
différentes. C'est précisément à ça que servent les génériques.
surement mais chez moi les poules ne font que de maniere tres
exceptionnelle des chevaux
et qd cela arrive cela s'appelle une erreur ou un bug
Oui, précisément, un bug. Les génériques, ça sert à détecter automatiquement
plus de bugs.
bon alors mets un vecteur dans l'obj si tu veux moi, tu sais je ne suis pas contrariant
Tu peux mettre tout ce que tu veux dedans, tu n'auras ni casts ni structures différentes. C'est précisément à ça que servent les génériques.
surement mais chez moi les poules ne font que de maniere tres exceptionnelle des chevaux et qd cela arrive cela s'appelle une erreur ou un bug
Oui, précisément, un bug. Les génériques, ça sert à détecter automatiquement plus de bugs.
On voit que tu sais ce dont tu parles, tiens...
Emmanuel Florac
Le Thu, 04 Jan 2007 09:40:37 +0100, remy a écrit :
un exemple ant a la main s'est pas rigolo c'est meme chiant a ecrire et le xml des conteneurs dans tomcat n'est vraiment pas evident a ecrire alrs a la main...
C'est pour ça qu'on fait plutôt des programmes pour ça :)
-- Le livre, comme livre, appartient à l'auteur, mais comme pensée, il appartient - le mot n'est pas trop vaste - au genre humain. Toutes les intelligences y ont droit. Si l'un des deux droits, le droit de l'écrivain et le droit de l'esprit humain, devait être sacrifié, ce serait, certes, le droit de l'écrivain, car l'intérêt public est notre préoccupation unique, et tous, je le déclare, doivent passer avant nous. Victor Hugo.
Le Thu, 04 Jan 2007 09:40:37 +0100, remy a écrit :
un exemple ant a la main s'est pas rigolo c'est meme chiant a ecrire
et le xml des conteneurs dans tomcat n'est vraiment pas evident a ecrire
alrs a la main...
C'est pour ça qu'on fait plutôt des programmes pour ça :)
--
Le livre, comme livre, appartient à l'auteur, mais comme pensée, il
appartient - le mot n'est pas trop vaste - au genre humain. Toutes les
intelligences y ont droit. Si l'un des deux droits, le droit de
l'écrivain et le droit de l'esprit humain, devait être sacrifié, ce
serait, certes, le droit de l'écrivain, car l'intérêt public est notre
préoccupation unique, et tous, je le déclare, doivent passer avant nous.
Victor Hugo.
Le Thu, 04 Jan 2007 09:40:37 +0100, remy a écrit :
un exemple ant a la main s'est pas rigolo c'est meme chiant a ecrire et le xml des conteneurs dans tomcat n'est vraiment pas evident a ecrire alrs a la main...
C'est pour ça qu'on fait plutôt des programmes pour ça :)
-- Le livre, comme livre, appartient à l'auteur, mais comme pensée, il appartient - le mot n'est pas trop vaste - au genre humain. Toutes les intelligences y ont droit. Si l'un des deux droits, le droit de l'écrivain et le droit de l'esprit humain, devait être sacrifié, ce serait, certes, le droit de l'écrivain, car l'intérêt public est notre préoccupation unique, et tous, je le déclare, doivent passer avant nous. Victor Hugo.
Emmanuel Florac
Le Thu, 04 Jan 2007 09:43:40 +0000, Michel Talon a écrit :
Oui, outre les enfants et les chimpanzés, c'est aussi le mode de fonctionnement des chercheurs ...
Je parlais d'utilisation de l'outil informatique par l'exploration, pas de l'exploration en général :)
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
Le Thu, 04 Jan 2007 09:43:40 +0000, Michel Talon a écrit :
Oui, outre les enfants et les chimpanzés, c'est aussi le mode de
fonctionnement des chercheurs ...
Je parlais d'utilisation de l'outil informatique par l'exploration, pas de
l'exploration en général :)
--
Mais monsieur, voudriez-vous que je me l'écorchasse?
Barbey d'Aurevilly.
Le Thu, 04 Jan 2007 09:43:40 +0000, Michel Talon a écrit :
Oui, outre les enfants et les chimpanzés, c'est aussi le mode de fonctionnement des chercheurs ...
Je parlais d'utilisation de l'outil informatique par l'exploration, pas de l'exploration en général :)
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
Emmanuel Florac
Le Thu, 04 Jan 2007 09:56:09 +0000, Michel Talon a écrit :
Et ceci avec un disque de portable qui est bien moins rapide qu'un disque de desktop, par contre le processeur est puissant.
Certes. Néammoins, une appli qui met 18s à démarrer c'est long. j'ai l'habitude d'un éditeur qui s'ouvre en un temps physiologiquement nul (moins de 100ms) :)
-- Toutes les organisations ont leur règles, et les Femmes Algériennes doivent avoir aussi leurs règles. Aït Ahmed.
Le Thu, 04 Jan 2007 09:56:09 +0000, Michel Talon a écrit :
Et ceci avec un disque de portable qui est bien moins rapide qu'un
disque de desktop, par contre le processeur est puissant.
Certes. Néammoins, une appli qui met 18s à démarrer c'est long. j'ai
l'habitude d'un éditeur qui s'ouvre en un temps physiologiquement nul
(moins de 100ms) :)
--
Toutes les organisations ont leur règles, et les Femmes Algériennes
doivent avoir aussi leurs règles.
Aït Ahmed.
Le Thu, 04 Jan 2007 09:56:09 +0000, Michel Talon a écrit :
Et ceci avec un disque de portable qui est bien moins rapide qu'un disque de desktop, par contre le processeur est puissant.
Certes. Néammoins, une appli qui met 18s à démarrer c'est long. j'ai l'habitude d'un éditeur qui s'ouvre en un temps physiologiquement nul (moins de 100ms) :)
-- Toutes les organisations ont leur règles, et les Femmes Algériennes doivent avoir aussi leurs règles. Aït Ahmed.
Emmanuel Florac
Le Thu, 04 Jan 2007 09:28:29 +0100, remy a écrit :
j'ai redecouvert un truc pour rendre le code illisible les Closures sont maintenant possibles en java :-(
Si ça continue ça deviendra presque utilisable alors ? :) Je n'imagine même pas qu'on puisse travailler sans closures...
-- Si non confectus non reficiat.
Le Thu, 04 Jan 2007 09:28:29 +0100, remy a écrit :
j'ai redecouvert un truc pour rendre le code illisible les Closures
sont maintenant possibles en java :-(
Si ça continue ça deviendra presque utilisable alors ? :) Je n'imagine
même pas qu'on puisse travailler sans closures...
