Le Thu, 23 Sep 2010 11:21:16 +0200,
remy écrivait :JKB a écrit :La raison est simple : développer toujours plus vite des logici els
jetables en assemblant des boîtes noires et en priant qu'il n'y ait
pas d'effet de bord. C'est même la raison d'être de la pro grammation
objet si tu regardes les choses dans le détail.
rassure moi ,tu troll lÃ
Non.
Le Thu, 23 Sep 2010 11:21:16 +0200,
remy <remy@fctpas.fr> écrivait :
JKB a écrit :
La raison est simple : développer toujours plus vite des logici els
jetables en assemblant des boîtes noires et en priant qu'il n'y ait
pas d'effet de bord. C'est même la raison d'être de la pro grammation
objet si tu regardes les choses dans le détail.
rassure moi ,tu troll lÃ
Non.
Le Thu, 23 Sep 2010 11:21:16 +0200,
remy écrivait :JKB a écrit :La raison est simple : développer toujours plus vite des logici els
jetables en assemblant des boîtes noires et en priant qu'il n'y ait
pas d'effet de bord. C'est même la raison d'être de la pro grammation
objet si tu regardes les choses dans le détail.
rassure moi ,tu troll lÃ
Non.
JKB a écrit :Le Thu, 23 Sep 2010 11:21:16 +0200,
remy écrivait :JKB a écrit :La raison est simple : développer toujours plus vite des logiciels
jetables en assemblant des boîtes noires et en priant qu'il n'y ait
pas d'effet de bord. C'est même la raison d'être de la programmation
objet si tu regardes les choses dans le détail.
rassure moi ,tu troll là
Non.
ok d'un point de vue conceptuel, puisque tu ne veux
pas des en gros,tu vois je fais des efforts
donc je disais ,que tu as le traitement de l'information
à proprement parler par exemple (tri ,calcul,fonction, etc,) et les
interaction de ses différents traitements
l'objet est une manière élégante de faire interagir les différents
traitements
dit différemment l'époque où on codait un tri avec un gain d'un pouillem
est finie, maintenant on utilise le tri pour le faire interagir
avec une autre fonctionnalité ,le gain d'un pouillem est devenu
négligeable ,c'est l'interaction qui donne le résultat escompté pas la
fonctionnalité,et il est absolument hors de question ,de tout recoder ou
de faire un bricolage à la con bien crade pour modifier une interaction
ou si tu préfères un code aux petits oignons qui trie des entiers
et performant oui, mais le jour où je veux trier des string il faut que
je recode tout, l'obj permet justement au prix de quelques pouillems
(dont j'en ai rien à foutre soit dit en passant ) de ne pas tout recoder
JKB a écrit :
Le Thu, 23 Sep 2010 11:21:16 +0200,
remy <remy@fctpas.fr> écrivait :
JKB a écrit :
La raison est simple : développer toujours plus vite des logiciels
jetables en assemblant des boîtes noires et en priant qu'il n'y ait
pas d'effet de bord. C'est même la raison d'être de la programmation
objet si tu regardes les choses dans le détail.
rassure moi ,tu troll là
Non.
ok d'un point de vue conceptuel, puisque tu ne veux
pas des en gros,tu vois je fais des efforts
donc je disais ,que tu as le traitement de l'information
à proprement parler par exemple (tri ,calcul,fonction, etc,) et les
interaction de ses différents traitements
l'objet est une manière élégante de faire interagir les différents
traitements
dit différemment l'époque où on codait un tri avec un gain d'un pouillem
est finie, maintenant on utilise le tri pour le faire interagir
avec une autre fonctionnalité ,le gain d'un pouillem est devenu
négligeable ,c'est l'interaction qui donne le résultat escompté pas la
fonctionnalité,et il est absolument hors de question ,de tout recoder ou
de faire un bricolage à la con bien crade pour modifier une interaction
ou si tu préfères un code aux petits oignons qui trie des entiers
et performant oui, mais le jour où je veux trier des string il faut que
je recode tout, l'obj permet justement au prix de quelques pouillems
(dont j'en ai rien à foutre soit dit en passant ) de ne pas tout recoder
JKB a écrit :Le Thu, 23 Sep 2010 11:21:16 +0200,
remy écrivait :JKB a écrit :La raison est simple : développer toujours plus vite des logiciels
jetables en assemblant des boîtes noires et en priant qu'il n'y ait
pas d'effet de bord. C'est même la raison d'être de la programmation
objet si tu regardes les choses dans le détail.
rassure moi ,tu troll là
Non.
ok d'un point de vue conceptuel, puisque tu ne veux
pas des en gros,tu vois je fais des efforts
donc je disais ,que tu as le traitement de l'information
à proprement parler par exemple (tri ,calcul,fonction, etc,) et les
interaction de ses différents traitements
l'objet est une manière élégante de faire interagir les différents
traitements
dit différemment l'époque où on codait un tri avec un gain d'un pouillem
est finie, maintenant on utilise le tri pour le faire interagir
avec une autre fonctionnalité ,le gain d'un pouillem est devenu
négligeable ,c'est l'interaction qui donne le résultat escompté pas la
fonctionnalité,et il est absolument hors de question ,de tout recoder ou
de faire un bricolage à la con bien crade pour modifier une interaction
ou si tu préfères un code aux petits oignons qui trie des entiers
et performant oui, mais le jour où je veux trier des string il faut que
je recode tout, l'obj permet justement au prix de quelques pouillems
(dont j'en ai rien à foutre soit dit en passant ) de ne pas tout recoder
Foutaises. Va tenir ton discours à un type qui utilise massivemen t
des fonctions de tri sur des grosses données et demande-lui ce qu 'il
pense de la fonction qsort() (par exemple). Ce type, s'il gagne des
pouillèmes, il est content. Tout le monde n'a pas à sa dispo sition
une machine surpuissante qui passe son temps à se tourner les pou ces !
Quand sur un serveur de base de données utilisé à 100% tu gagnes ne
serait-ce que 5% sur un algorithme de tri, tu es _très_ content
parce que ça te permet de traiter 5% de données en plus. Mai ntenant,
pour être très clair avec toi, ce que tu peux gagner en un
algorithme générique et un algorithme optimisé, ce n'es t pas de
l'ordre de 5%, c'est souvent beaucoup plus.
Foutaises. Va tenir ton discours à un type qui utilise massivemen t
des fonctions de tri sur des grosses données et demande-lui ce qu 'il
pense de la fonction qsort() (par exemple). Ce type, s'il gagne des
pouillèmes, il est content. Tout le monde n'a pas à sa dispo sition
une machine surpuissante qui passe son temps à se tourner les pou ces !
Quand sur un serveur de base de données utilisé à 100% tu gagnes ne
serait-ce que 5% sur un algorithme de tri, tu es _très_ content
parce que ça te permet de traiter 5% de données en plus. Mai ntenant,
pour être très clair avec toi, ce que tu peux gagner en un
algorithme générique et un algorithme optimisé, ce n'es t pas de
l'ordre de 5%, c'est souvent beaucoup plus.
Foutaises. Va tenir ton discours à un type qui utilise massivemen t
des fonctions de tri sur des grosses données et demande-lui ce qu 'il
pense de la fonction qsort() (par exemple). Ce type, s'il gagne des
pouillèmes, il est content. Tout le monde n'a pas à sa dispo sition
une machine surpuissante qui passe son temps à se tourner les pou ces !
Quand sur un serveur de base de données utilisé à 100% tu gagnes ne
serait-ce que 5% sur un algorithme de tri, tu es _très_ content
parce que ça te permet de traiter 5% de données en plus. Mai ntenant,
pour être très clair avec toi, ce que tu peux gagner en un
algorithme générique et un algorithme optimisé, ce n'es t pas de
l'ordre de 5%, c'est souvent beaucoup plus.
JKB a écrit :
Foutaises. Va tenir ton discours à un type qui utilise massivement
des fonctions de tri sur des grosses données et demande-lui ce qu'il
pense de la fonction qsort() (par exemple). Ce type, s'il gagne des
pouillèmes, il est content. Tout le monde n'a pas à sa disposition
une machine surpuissante qui passe son temps à se tourner les pouces !
Quand sur un serveur de base de données utilisé à 100% tu gagnes ne
serait-ce que 5% sur un algorithme de tri, tu es _très_ content
parce que ça te permet de traiter 5% de données en plus. Maintenant,
pour être très clair avec toi, ce que tu peux gagner en un
algorithme générique et un algorithme optimisé, ce n'est pas de
l'ordre de 5%, c'est souvent beaucoup plus.
connerie il m'est arrivé d'attaquer des bases de données
qui ont plusieurs dizaines de milliers d'entrées avec des tables dans
tout les sens voire même sur plusieurs bases de données, et le jour où
il décide de mettre de l'ordre ou de changer les tables, sans
abstraction, tu es dans la merde et pas qu'un peu
tu prends ton clavier et tu écris
les pouillemes je m'en bats les couilles avec une pelle à tarte contre
un mur en crépi ,je veux du code modulaire et robuste
tu verras la vie différemment ,si si je te promets
après 2,3 semaines de ce traitement intensif
tu seras prêt pour écrire une recherche de nombres premiers en java ,
parce que le but n'est pas de faire tomber le record,mais de vérifier
"la théorie"
JKB a écrit :
Foutaises. Va tenir ton discours à un type qui utilise massivement
des fonctions de tri sur des grosses données et demande-lui ce qu'il
pense de la fonction qsort() (par exemple). Ce type, s'il gagne des
pouillèmes, il est content. Tout le monde n'a pas à sa disposition
une machine surpuissante qui passe son temps à se tourner les pouces !
Quand sur un serveur de base de données utilisé à 100% tu gagnes ne
serait-ce que 5% sur un algorithme de tri, tu es _très_ content
parce que ça te permet de traiter 5% de données en plus. Maintenant,
pour être très clair avec toi, ce que tu peux gagner en un
algorithme générique et un algorithme optimisé, ce n'est pas de
l'ordre de 5%, c'est souvent beaucoup plus.
connerie il m'est arrivé d'attaquer des bases de données
qui ont plusieurs dizaines de milliers d'entrées avec des tables dans
tout les sens voire même sur plusieurs bases de données, et le jour où
il décide de mettre de l'ordre ou de changer les tables, sans
abstraction, tu es dans la merde et pas qu'un peu
tu prends ton clavier et tu écris
les pouillemes je m'en bats les couilles avec une pelle à tarte contre
un mur en crépi ,je veux du code modulaire et robuste
tu verras la vie différemment ,si si je te promets
après 2,3 semaines de ce traitement intensif
tu seras prêt pour écrire une recherche de nombres premiers en java ,
parce que le but n'est pas de faire tomber le record,mais de vérifier
"la théorie"
JKB a écrit :
Foutaises. Va tenir ton discours à un type qui utilise massivement
des fonctions de tri sur des grosses données et demande-lui ce qu'il
pense de la fonction qsort() (par exemple). Ce type, s'il gagne des
pouillèmes, il est content. Tout le monde n'a pas à sa disposition
une machine surpuissante qui passe son temps à se tourner les pouces !
Quand sur un serveur de base de données utilisé à 100% tu gagnes ne
serait-ce que 5% sur un algorithme de tri, tu es _très_ content
parce que ça te permet de traiter 5% de données en plus. Maintenant,
pour être très clair avec toi, ce que tu peux gagner en un
algorithme générique et un algorithme optimisé, ce n'est pas de
l'ordre de 5%, c'est souvent beaucoup plus.
connerie il m'est arrivé d'attaquer des bases de données
qui ont plusieurs dizaines de milliers d'entrées avec des tables dans
tout les sens voire même sur plusieurs bases de données, et le jour où
il décide de mettre de l'ordre ou de changer les tables, sans
abstraction, tu es dans la merde et pas qu'un peu
tu prends ton clavier et tu écris
les pouillemes je m'en bats les couilles avec une pelle à tarte contre
un mur en crépi ,je veux du code modulaire et robuste
tu verras la vie différemment ,si si je te promets
après 2,3 semaines de ce traitement intensif
tu seras prêt pour écrire une recherche de nombres premiers en java ,
parce que le but n'est pas de faire tomber le record,mais de vérifier
"la théorie"
Le Thu, 23 Sep 2010 14:57:24 +0200,
remy écrivait :JKB a écrit :Foutaises. Va tenir ton discours à un type qui utilise massivem ent
des fonctions de tri sur des grosses données et demande-lui ce qu'il
pense de la fonction qsort() (par exemple). Ce type, s'il gagne des
pouillèmes, il est content. Tout le monde n'a pas à sa dis position
une machine surpuissante qui passe son temps à se tourner les p ouces !
Quand sur un serveur de base de données utilisé à 100 % tu gagnes ne
serait-ce que 5% sur un algorithme de tri, tu es _très_ content
parce que ça te permet de traiter 5% de données en plus. M aintenant,
pour être très clair avec toi, ce que tu peux gagner en un
algorithme générique et un algorithme optimisé, ce n' est pas de
l'ordre de 5%, c'est souvent beaucoup plus.
connerie il m'est arrivé d'attaquer des bases de données
qui ont plusieurs dizaines de milliers d'entrées avec des table s dans
tout les sens voire même sur plusieurs bases de données, et le jour où
il décide de mettre de l'ordre ou de changer les tables, sans
abstraction, tu es dans la merde et pas qu'un peu
Je ne vois pas pourquoi je discute avec un type comme toi. Tu es
bouché à l'émeri. Le type qui a codé un algorithme de tri dans une
base comme Postgre, crois-tu qu'il a utilisé bêtement un tru c
existant ? Non, il l'a codé avec ses petites mimines pour que son
algorithme de tri colle au mieux à ses données. Faire autre chose
est une connerie incommensurable.
Le Thu, 23 Sep 2010 14:57:24 +0200,
remy <remy@fctpas.fr> écrivait :
JKB a écrit :
Foutaises. Va tenir ton discours à un type qui utilise massivem ent
des fonctions de tri sur des grosses données et demande-lui ce qu'il
pense de la fonction qsort() (par exemple). Ce type, s'il gagne des
pouillèmes, il est content. Tout le monde n'a pas à sa dis position
une machine surpuissante qui passe son temps à se tourner les p ouces !
Quand sur un serveur de base de données utilisé à 100 % tu gagnes ne
serait-ce que 5% sur un algorithme de tri, tu es _très_ content
parce que ça te permet de traiter 5% de données en plus. M aintenant,
pour être très clair avec toi, ce que tu peux gagner en un
algorithme générique et un algorithme optimisé, ce n' est pas de
l'ordre de 5%, c'est souvent beaucoup plus.
connerie il m'est arrivé d'attaquer des bases de données
qui ont plusieurs dizaines de milliers d'entrées avec des table s dans
tout les sens voire même sur plusieurs bases de données, et le jour où
il décide de mettre de l'ordre ou de changer les tables, sans
abstraction, tu es dans la merde et pas qu'un peu
Je ne vois pas pourquoi je discute avec un type comme toi. Tu es
bouché à l'émeri. Le type qui a codé un algorithme de tri dans une
base comme Postgre, crois-tu qu'il a utilisé bêtement un tru c
existant ? Non, il l'a codé avec ses petites mimines pour que son
algorithme de tri colle au mieux à ses données. Faire autre chose
est une connerie incommensurable.
Le Thu, 23 Sep 2010 14:57:24 +0200,
remy écrivait :JKB a écrit :Foutaises. Va tenir ton discours à un type qui utilise massivem ent
des fonctions de tri sur des grosses données et demande-lui ce qu'il
pense de la fonction qsort() (par exemple). Ce type, s'il gagne des
pouillèmes, il est content. Tout le monde n'a pas à sa dis position
une machine surpuissante qui passe son temps à se tourner les p ouces !
Quand sur un serveur de base de données utilisé à 100 % tu gagnes ne
serait-ce que 5% sur un algorithme de tri, tu es _très_ content
parce que ça te permet de traiter 5% de données en plus. M aintenant,
pour être très clair avec toi, ce que tu peux gagner en un
algorithme générique et un algorithme optimisé, ce n' est pas de
l'ordre de 5%, c'est souvent beaucoup plus.
connerie il m'est arrivé d'attaquer des bases de données
qui ont plusieurs dizaines de milliers d'entrées avec des table s dans
tout les sens voire même sur plusieurs bases de données, et le jour où
il décide de mettre de l'ordre ou de changer les tables, sans
abstraction, tu es dans la merde et pas qu'un peu
Je ne vois pas pourquoi je discute avec un type comme toi. Tu es
bouché à l'émeri. Le type qui a codé un algorithme de tri dans une
base comme Postgre, crois-tu qu'il a utilisé bêtement un tru c
existant ? Non, il l'a codé avec ses petites mimines pour que son
algorithme de tri colle au mieux à ses données. Faire autre chose
est une connerie incommensurable.
Je vais juste te donner un exemple parce que vu ton niveau
d'abstraction, il n'y a que ça que tu peux comprendre. Si j'ai un
algorithme de conversion d'une adresse postale en (x,y) et que je
m'appelle par exemple Mappy, j'ai une base de données de 10 Go
contenant toutes les voies françaises (c'est la taille de la base
NavTeq que j'ai sur ma machine). Si je gagne ne serait-ce que
10% dans les traitements parce que je n'ai pas écrit un tri
générique avec mon pied gauche, je gagne 10% de la capacità © de mes
serveurs, ce qui est immédiatement _beaucoup_ d'argent.
Si maintenant, tu pars des fonctions génériques de BOOST qui font ça
très bien et que tu arrives sur tes propres fonctions optimisé es aux
petites oignons, tu peux avoir en vitesse d'exécution un rapport de
1 à 10. Je ne sais pas si tu vois bien ce que ça représ ente. Vu ta
façon de penser, j'ai comme un doute.
Maintenant, que ton PC chauffe durant quinze jours avec tes
algorithmes à la noix, on s'en contrefiche !
Je vais juste te donner un exemple parce que vu ton niveau
d'abstraction, il n'y a que ça que tu peux comprendre. Si j'ai un
algorithme de conversion d'une adresse postale en (x,y) et que je
m'appelle par exemple Mappy, j'ai une base de données de 10 Go
contenant toutes les voies françaises (c'est la taille de la base
NavTeq que j'ai sur ma machine). Si je gagne ne serait-ce que
10% dans les traitements parce que je n'ai pas écrit un tri
générique avec mon pied gauche, je gagne 10% de la capacità © de mes
serveurs, ce qui est immédiatement _beaucoup_ d'argent.
Si maintenant, tu pars des fonctions génériques de BOOST qui font ça
très bien et que tu arrives sur tes propres fonctions optimisé es aux
petites oignons, tu peux avoir en vitesse d'exécution un rapport de
1 à 10. Je ne sais pas si tu vois bien ce que ça représ ente. Vu ta
façon de penser, j'ai comme un doute.
Maintenant, que ton PC chauffe durant quinze jours avec tes
algorithmes à la noix, on s'en contrefiche !
Je vais juste te donner un exemple parce que vu ton niveau
d'abstraction, il n'y a que ça que tu peux comprendre. Si j'ai un
algorithme de conversion d'une adresse postale en (x,y) et que je
m'appelle par exemple Mappy, j'ai une base de données de 10 Go
contenant toutes les voies françaises (c'est la taille de la base
NavTeq que j'ai sur ma machine). Si je gagne ne serait-ce que
10% dans les traitements parce que je n'ai pas écrit un tri
générique avec mon pied gauche, je gagne 10% de la capacità © de mes
serveurs, ce qui est immédiatement _beaucoup_ d'argent.
Si maintenant, tu pars des fonctions génériques de BOOST qui font ça
très bien et que tu arrives sur tes propres fonctions optimisé es aux
petites oignons, tu peux avoir en vitesse d'exécution un rapport de
1 à 10. Je ne sais pas si tu vois bien ce que ça représ ente. Vu ta
façon de penser, j'ai comme un doute.
Maintenant, que ton PC chauffe durant quinze jours avec tes
algorithmes à la noix, on s'en contrefiche !
mauvaise exemple ,il n'y a pas de trie associer a un type de donnée
mauvaise exemple ,il n'y a pas de trie associer a un type de donnée
mauvaise exemple ,il n'y a pas de trie associer a un type de donnée
Je vais juste te donner un exemple parce que vu ton niveau
d'abstraction, il n'y a que ça que tu peux comprendre. Si j'ai un
algorithme de conversion d'une adresse postale en (x,y) et que je
m'appelle par exemple Mappy, j'ai une base de données de 10 Go
contenant toutes les voies françaises (c'est la taille de la base
NavTeq que j'ai sur ma machine). Si je gagne ne serait-ce que
10% dans les traitements parce que je n'ai pas écrit un tri
générique avec mon pied gauche, je gagne 10% de la capacité de mes
serveurs, ce qui est immédiatement _beaucoup_ d'argent.
Je vais juste te donner un exemple parce que vu ton niveau
d'abstraction, il n'y a que ça que tu peux comprendre. Si j'ai un
algorithme de conversion d'une adresse postale en (x,y) et que je
m'appelle par exemple Mappy, j'ai une base de données de 10 Go
contenant toutes les voies françaises (c'est la taille de la base
NavTeq que j'ai sur ma machine). Si je gagne ne serait-ce que
10% dans les traitements parce que je n'ai pas écrit un tri
générique avec mon pied gauche, je gagne 10% de la capacité de mes
serveurs, ce qui est immédiatement _beaucoup_ d'argent.
Je vais juste te donner un exemple parce que vu ton niveau
d'abstraction, il n'y a que ça que tu peux comprendre. Si j'ai un
algorithme de conversion d'une adresse postale en (x,y) et que je
m'appelle par exemple Mappy, j'ai une base de données de 10 Go
contenant toutes les voies françaises (c'est la taille de la base
NavTeq que j'ai sur ma machine). Si je gagne ne serait-ce que
10% dans les traitements parce que je n'ai pas écrit un tri
générique avec mon pied gauche, je gagne 10% de la capacité de mes
serveurs, ce qui est immédiatement _beaucoup_ d'argent.
On 9/23/10 9:08 PM, JKB wrote:Je vais juste te donner un exemple parce que vu ton niveau
d'abstraction, il n'y a que ça que tu peux comprendre. Si j'a i un
algorithme de conversion d'une adresse postale en (x,y) et que je
m'appelle par exemple Mappy, j'ai une base de données de 10 G o
contenant toutes les voies françaises (c'est la taille de la base
NavTeq que j'ai sur ma machine). Si je gagne ne serait-ce que
10% dans les traitements parce que je n'ai pas écrit un tri
générique avec mon pied gauche, je gagne 10% de la capac ité de mes
serveurs, ce qui est immédiatement _beaucoup_ d'argent.
Le truc justement, c'est que NON, ca ne fait pas beaucoup d'argent. Et
ca a meme de fortes chances de couter bien moins cher que l'inge qui a
passe 2 mois a re-inventer la lune et qui va en repasser 2 a corriger
ses bugs.
On 9/23/10 9:08 PM, JKB wrote:
Je vais juste te donner un exemple parce que vu ton niveau
d'abstraction, il n'y a que ça que tu peux comprendre. Si j'a i un
algorithme de conversion d'une adresse postale en (x,y) et que je
m'appelle par exemple Mappy, j'ai une base de données de 10 G o
contenant toutes les voies françaises (c'est la taille de la base
NavTeq que j'ai sur ma machine). Si je gagne ne serait-ce que
10% dans les traitements parce que je n'ai pas écrit un tri
générique avec mon pied gauche, je gagne 10% de la capac ité de mes
serveurs, ce qui est immédiatement _beaucoup_ d'argent.
Le truc justement, c'est que NON, ca ne fait pas beaucoup d'argent. Et
ca a meme de fortes chances de couter bien moins cher que l'inge qui a
passe 2 mois a re-inventer la lune et qui va en repasser 2 a corriger
ses bugs.
On 9/23/10 9:08 PM, JKB wrote:Je vais juste te donner un exemple parce que vu ton niveau
d'abstraction, il n'y a que ça que tu peux comprendre. Si j'a i un
algorithme de conversion d'une adresse postale en (x,y) et que je
m'appelle par exemple Mappy, j'ai une base de données de 10 G o
contenant toutes les voies françaises (c'est la taille de la base
NavTeq que j'ai sur ma machine). Si je gagne ne serait-ce que
10% dans les traitements parce que je n'ai pas écrit un tri
générique avec mon pied gauche, je gagne 10% de la capac ité de mes
serveurs, ce qui est immédiatement _beaucoup_ d'argent.
Le truc justement, c'est que NON, ca ne fait pas beaucoup d'argent. Et
ca a meme de fortes chances de couter bien moins cher que l'inge qui a
passe 2 mois a re-inventer la lune et qui va en repasser 2 a corriger
ses bugs.
remy a suggéré :
mauvaise exemple ,il n'y a pas de trie associer a un type de donnée
bien sûr que si.
tu ne vas pas utiliser la même méthode (donc pas le même algo) pour
trier un carnet d'adresses ou une encyclopédie, ou des photos, ou des
fichiers sons, ou des informations topographiques....
remy <remy@fctpas.fr> a suggéré :
mauvaise exemple ,il n'y a pas de trie associer a un type de donnée
bien sûr que si.
tu ne vas pas utiliser la même méthode (donc pas le même algo) pour
trier un carnet d'adresses ou une encyclopédie, ou des photos, ou des
fichiers sons, ou des informations topographiques....
remy a suggéré :
mauvaise exemple ,il n'y a pas de trie associer a un type de donnée
bien sûr que si.
tu ne vas pas utiliser la même méthode (donc pas le même algo) pour
trier un carnet d'adresses ou une encyclopédie, ou des photos, ou des
fichiers sons, ou des informations topographiques....