그래서 테이블 생성자에는 list-like와 record-like의 두 가지 구성 요소가 있습니다. 목록과 같은 항목은 항상 레코드와 비슷한 항목보다 우선합니까? 나는, 다음 시나리오를 고려 의미 : 루아 테이블 생성자의 초기화 순서
a = {[1]=1, [2]=2, 3}
print(a[1]) -- 3
a = {1, [2]=2, [1]=3}
print(a[1]) -- 1
인덱스 1는 항상 두 번째로 첫 번째 목록과 같은 항목 2와 연관되어
루아의 테이블에는 두 가지 유형, 배열 및 사전이 당신이 "목록"과 "기록"을 부르는 것입니다있다. 배열에는 순서대로 값이 포함되어 있으므로 더 빠른 반복 또는 값 삽입/제거와 같은 몇 가지 이점이 있습니다. 사전은 거대한 조회 테이블처럼 작동하지만 순서가 없습니다. 이점은 키로 어떤 값을 사용할 수 있으며 제한이없는 것입니다.
테이블을 만들 때 구문이 2 개인 경우 쉼표로 값을 구분할 수 있습니다 (예 : {2,4,6,8} 키를 사용하여 배열을 만들거나 1에서 n까지의 키를 사용하여 키 - 값 쌍을 정의 할 수 있습니다. {[1]=2,[58]=4,[368]=6,[48983]=8}사전을 작성하면 이러한 구문을 혼용 할 수 있으며 어떤 문제도 발생하지 않습니다. 이지만 시나리오에는 해당하지 않습니다.
테이블의 초기 구성 중에 동일한 키를 두 번 정의하고 있습니다. 이것은 가장 일반적으로 비실용적이며 언어 개발 과정에서 진지하게 생각해 본적이 없습니다. 즉, 기본적으로 지정되지 않은 동작입니다. 이것이 어떤 영향을 미치는지 완전히 이해하지 못하고 있으며 다른 플랫폼이나 구현에서 일관성이 없을 수 있습니다.
마찬가지로 상업 프로젝트 나 다른 사람들과 공유 할 코드에는이 코드를 사용하지 마십시오. 의심스러운 경우 빈 테이블을 만들고 나중에 키 - 값 쌍을 정의하십시오.
_ "[...]은 언어 개발 과정에서 실제로 생각하지 못했습니다."_ 올바르지 않습니다. 그것은 고려되었지만, 이것을 점검하는 비용 (시간과 코드의 복잡성 모두)은 이점을 능가하므로 체크가되지 않습니다. 추가적으로 (minor nit-pick) 동작은 _undefined_하지만 _unspecified_ (적어도 C 및 C++ 표준에서 사용되는 언어로는) - 어떤 일이 발생할 수있는 경우가 아니며, 단지 equal 키가 정의되지 않았습니다. – nobody
@nobody 그것이 고려 된 출처인가요? * unspecified *에서 편집합니다. – warspyking
찾고있는 스 니펫을 찾을 수 없지만이 교환 [1] (http://lua-users.org/lists/lua-l/2007-03/msg00277.html), [2] (http://lua-users.org/lists/lua-l/2007-03/msg00280.html) Lua-ML ~ 10 년 전 그들은 그 당시에 그것을 알고 있었고 독립형 정적 검사기. 그 논리를 루아로 옮기는 것은 명백한 가능성이 있습니다 (그래서 나는 옵션이 고려되었다고 생각합니다), 그러나 중복 키에 대한 루아의 행동은 이후 출시 된 몇몇 새 버전에서 변경되지 않았습니다. – nobody
'a = {1, [2] = 2, [1] = 3}'의 결과는 지정되지 않습니다. 실제 결과는 PUC Lua와 LuaJIT에서 다를 수 있습니다. 프로덕션 환경에서 이러한 코드를 사용하지 마십시오. –
@EgorSkriptunoff 그런데'a = {[1] = 1, [2] = 2, 3}'의 결과가 있어야합니까? – ibrahim5253
[UB] (https://en.wikipedia.org/wiki/Unspecified_behavior) –