Certes, une fois que l'attaque est connue, tu peux faire ce qu'il faut pour la contourner. Mais dans ce cas, tu fais pareil avec une table hash en limitant par exemple le nombre d'éléments insérables (solution PHP). Ou bien tu aléatoirises le hachage (solution Perl, et je crois qu'on se dirige vers ça côté Python).
Avec le même genre d'arguments, un tri à bulles est préférable à un tri rapide parce que le tri à bulles, lui, est toujours lent. La bonne solution est plutôt de s'assurer que l'algo de tri ne peut facilement dégénérer, sans être d'emblée non plus en O(n**2).
[^] # Re: N'optimiser que si nécessaire
Posté par Antoine . En réponse à la dépêche Le colonel Moutarde, sur la table (de hachage), avec un livre de maths. Évalué à 3.
Certes, une fois que l'attaque est connue, tu peux faire ce qu'il faut pour la contourner. Mais dans ce cas, tu fais pareil avec une table hash en limitant par exemple le nombre d'éléments insérables (solution PHP). Ou bien tu aléatoirises le hachage (solution Perl, et je crois qu'on se dirige vers ça côté Python).
Avec le même genre d'arguments, un tri à bulles est préférable à un tri rapide parce que le tri à bulles, lui, est toujours lent. La bonne solution est plutôt de s'assurer que l'algo de tri ne peut facilement dégénérer, sans être d'emblée non plus en O(n**2).