2009-08-10 5 views

Répondre

26

Yes. De perldoc -f keys:

Les clés sont retournées dans un ordre apparemment aléatoire. L'ordre aléatoire réel est sujet à changement dans les futures versions de perl, mais il est garanti d'être dans le même ordre que la fonction values ou each produit (étant donné que le hachage n'a pas été modifié). Depuis Perl 5.8.1 l'ordre est différent même entre les différentes exécutions de Perl pour des raisons de sécurité (voir "Algorithmic Complexity Attacks" dans perldoc perlsec).

(Souligné par l'auteur)

+12

+1 Ce serait génial si les gens essayaient au moins de lire l'excellente documentation fournie avec Perl. –

-2

Cette attente est assez casse-gueule. Ce sera probablement le cas, mais pourquoi s'inquiéter? Récupérez les clés à l'avance, enregistrez le résultat, puis passez en revue le résultat enregistré. Ensuite, vous avez la garantie d'accéder aux clés dans le même ordre. Il est dangereux de contourner les détails d'implémentation non spécifiés.

EDIT: J'ai manqué la "garantie" dans le document, mais je pense toujours qu'il est dangereux de s'attendre à ce que cela ne change jamais. Surtout quand il y a des moyens plus sains d'atteindre les mêmes objectifs.

+2

Pourquoi les citations effrayantes autour de "garantir"?C'est (a) très clairement énoncé; (b) peu susceptible de changer, car il est important que 'keys' et' values' reviennent dans le même ordre, de sorte que les deux peuvent être corrélés lorsque vous ne pouvez pas utiliser 'each'. – derobert

0

Edit:

Bien qu'un hachage normale a un ordre cohérent, dans le cas d'un tied hash l'ordre des clés est pas bien défini, car il est contrôlé par l'utilisateur! Bien que l'ordre des clés de hachage ne change pas, vous devriez probablement reconsidérer la raison pour laquelle vous devez le faire.

Peut-être que vous pouvez traiter le hachage en un seul passage au lieu de deux? Vous devez enregistrer les clés de hachage dans un tableau en tant que pratique de programmation défensive, à moins que la taille des données ne soit suffisamment importante pour que la duplication soit un problème. En prime, vous pouvez même trier la liste facilement et traiter dans le hachage dans un ordre bien défini. Par exemple,

my @keys = sort keys %myHash; 

Cela évite tout problème avec la modification du hachage, puisque votre commande de tableau ne changera jamais, sauf si vous le souhaitez. Si vous ne faites pas cela, vous devez faire très attention de ne rien faire qui change le hachage, sinon l'ordre des éléments changera. Regardez dans le module Readonly pour vous assurer que ce hachage n'est jamais modifié.

+0

Je ne comprends pas - pourquoi devriez-vous être sur la défensive à propos d'une fonctionnalité testée, documentée et donc garantie de fonctionner? Cela semble tout aussi bête que d'utiliser un éditeur de texte et d'appeler File -> Safe deux fois dans une rangée dans l'espoir que si le premier échoue silencieusement, le second réussira. – moritz

+2

@moritz: Le problème n'est pas que Perl change l'ordre des clés (ou non), c'est que l'ordre peut changer si le hachage est modifié. Cette réponse suggère une tactique de programmation défensive (array séparé plus Readonly) pour la maintenance future de la base de code de l'OP, et n'a rien à voir avec les internes de Perl. –

+3

À moins de bonnes raisons de ne pas le faire, j'essaie de toujours trier. Été mordu trop souvent par le code qui s'attend implicitement à un certain ordre et commence à échouer mystérieusement lorsque des changements apparemment sans rapport se traduisent par un ordre différent des clés. – ysth

Questions connexes