Go에서 새 슬라이스를 생성할 때 루프에 추가된 슬라이스가 예기치 않은 동작을 보이는 이유는 무엇입니까?

Go에서 예기치 않은 슬라이스 추가 동작

Go 프로그래밍 영역에서 슬라이스에 요소를 추가할 때 비정상적인 동작이 발생했습니다. 루프를 생성한 후 루프 결과를 기반으로 새 슬라이스를 생성하려고 시도합니다. 흥미롭게도 마지막 추가 작업은 이전 추가에서 생성된 슬라이스를 재정의합니다.

문제 탐색

다음 코드 조각을 고려하세요.

<code class="go">func create(iterations int) []int {
    a := make([]int, 0)
    for i := 0; i < iterations; i++ {
        a = append(a, i)
    }
    return a
}</code>

create(11)을 호출하고 요소를 추가하여 새 슬라이스를 생성하는 경우(예: j := append(i, 100), g :=append(i, 101), h :=append(i, 102)), 이러한 슬라이스(j, g 및 h)의 마지막 요소는 100, 101이 될 것으로 예상됩니다. , 및 102입니다. 그러나 놀랍게도 이 경우에는 모두 102가 됩니다.

이 동작은 아래 설명된 것처럼 슬라이스 리터럴에서 새 슬라이스를 생성할 때 발생하는 상황과 극명한 대조를 이룹니다.

<code class="go">func sliceFromLiteral() {
    i := []int{0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10}
    j := append(i, 100)
    g := append(i, 101)
    h := append(i, 102)
    fmt.Printf("i: %v\nj: %v\ng: %v\nh:%v\n", i, j, g, h)
}</code>

이 경우 j, g, h는 예상되는 동작을 나타내며 마지막 요소는 100, 101, 102입니다.

근본 원인 조사

이 예상치 못한 동작 뒤에 숨은 수수께끼를 풀려면 추가 작업이 기본 배열을 수정할 뿐만 아니라 새로운 슬라이스를 반환합니다. 이는 슬라이스 j, g 및 h가 실제로 동일한 기본 배열을 가리키고 있음을 의미합니다. 따라서 마지막 추가(append(i, 102))가 수행되면 기본 배열의 마지막 요소가 수정되어 j, g 및 h의 값이 효과적으로 재정의됩니다.

관용적 해결 방법

이러한 예기치 않은 동작을 방지하려면 추가를 시도하기 전에 슬라이스를 복사하는 것이 중요합니다. 이렇게 하면 새로운 기본 배열이 생성되어 원본 슬라이스가 수정되지 않은 상태로 유지됩니다. 다음 코드는 기존 슬라이스를 기반으로 여러 개의 새 슬라이스를 생성하는 관용적 방법을 보여줍니다.

<code class="go">func makeFromSlice(sl []int) []int {
    result := make([]int, len(sl))
    copy(result, sl)
    return result
}</code>

이 접근 방식을 사용하면 원본 데이터의 무결성을 유지하면서 손쉽게 새 슬라이스를 생성할 수 있습니다.

슬라이스 리터럴 예외

생성된 슬라이스에서 관찰되는 특이한 동작 from 루프는 리터럴에서 초기화된 슬라이스로 확장되지 않습니다. 이는 추가 작업이 지원 배열의 용량을 초과하는 경우 Go가 새 배열을 할당한다는 사실에 기인합니다. 이 동작은 슬라이스가 리터럴 또는 변수에서 생성되는지 여부와 무관하며 Go에서 내부적으로 배열이 처리되는 방식의 결과일 뿐입니다.

위 내용은 Go에서 새 슬라이스를 생성할 때 루프에 추가된 슬라이스가 예기치 않은 동작을 보이는 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!