2017-02-15 1 views
1

Ainsi, un constructeur de table a deux composants, comme des listes et des enregistrements. Les entrées de type liste ont-elles toujours la préséance sur celles qui ressemblent à des enregistrements? Je veux dire, considère le scénario suivant:Ordre d'initialisation dans Lua Table Constructeur

a = {[1]=1, [2]=2, 3} 
print(a[1]) -- 3 
a = {1, [2]=2, [1]=3} 
print(a[1]) -- 1 

est l'indice 1 toujours associé à la première entrée de type liste, 2 avec le deuxième, et ainsi de suite? Ou y a-t-il autre chose?

+2

Le résultat de 'a = {1, [2] = 2, [1] = 3}' n'est pas spécifié. Les vrais résultats seront différents sur PUC Lua et sur LuaJIT. N'utilisez pas ce code dans la production. –

+0

@EgorSkriptunoff Alors devrait être le résultat de 'a = {[1] = 1, [2] = 2, 3}'? – ibrahim5253

+0

[UB] (https://fr.wikipedia.org/wiki/Unspecified_behavior) –

Répondre

0

Il existe deux types de tables dans Lua, tableaux et dictionnaires, ce sont ce que vous appelez des « listes » et « documents ». Un tableau, contient des valeurs dans un ordre, cela vous donne quelques avantages, comme une itération plus rapide ou l'insertion/suppression de valeurs. Dictionnaires fonctionnent comme une table de recherche géante, il n'a pas d'ordre, ses avantages sont de savoir comment vous pouvez utiliser n'importe quelle valeur comme une clé, et vous n'êtes pas aussi restreint. Lorsque vous construisez une table, vous avez 2 syntaxes, vous pouvez séparer les valeurs par des virgules, par ex. {2,4,6,8} créant ainsi un tableau avec les touches 1 à n, ou vous pouvez définir des paires clé-valeur, par ex. {[1]=2,[58]=4,[368]=6,[48983]=8} créer un dictionnaire, vous pouvez souvent mélanger ces syntaxes et vous ne rencontrerez aucun problème, mais ce n'est pas le cas dans votre scénario.

Ce que vous faites est de définir la même clé deux fois pendant la construction initiale de la table. Ceci est le plus souvent impraticable et en tant que tel n'a pas vraiment eu de pensée sérieuse dans le développement de la langue. Cela signifie que ce qui se passe est essentiellement comportement non spécifié. Il n'est pas complètement compris quel effet cela aura, et peut être incohérent entre différentes plates-formes ou implémentations. En tant que tel, vous ne devriez pas l'utiliser dans des projets commerciaux, ou tout code que vous partagerez avec d'autres personnes. En cas de doute, construisez une table vide et définissez les paires clé-valeur par la suite.

+1

_ "[...] n'a pas vraiment été pensé pendant le développement de la langue" _ est incorrect. Il a été envisagé, mais le coût de la vérification (temps et complexité du code) l'emportent sur les avantages, il n'y a donc pas de vérification. En outre (mineur nit-pick), le comportement n'est pas _undefined_ mais _unspecified_ (au moins dans la langue utilisée dans la norme C et C++) - ce n'est pas le cas que tout peut arriver, simplement que l'ordre d'affectation pour égal les clés ne sont pas définies. – nobody

+0

@nobody Source à laquelle il a été pensé? Éditera également dans * non spécifié * – warspyking

+0

Impossible de trouver l'extrait que je cherchais mais cet échange [1] (http://lua-users.org/lists/lua-l/2007-03/msg00277.html), [2] (http://lua-users.org/lists/lua-l/2007-03/msg00280.html) sur le Lua-ML ~ il y a dix ans montre qu'ils étaient conscients de cela à l'époque et avaient un travail vérificateur statique autonome. Déplacer cette logique dans Lua est une possibilité évidente (donc je suppose que cette option a été considérée), mais le comportement de Lua pour les clés en double n'a pas changé à travers plusieurs nouvelles versions publiées depuis. – nobody