컴파일 오류 없이 다양한 런타임 유형에 대한 Go Generic 컨테이너를 어떻게 만들 수 있나요?

다양한 런타임 유형의 Go 일반 컨테이너

Go에서는 모든 유형의 데이터를 처리할 수 있는 일반 컨테이너를 만드는 기능으로 코드 유연성이 향상됩니다. . 그러나 채널에 잠재적으로 모든 유형의 데이터가 포함될 수 있으므로 goroutine 시작 중에 채널 유형을 지정하는 것은 어려울 수 있습니다.

초기 접근 방식:

처음에는 Go 1.18에 새로 도입된 제네릭을 다음과 같이 활용하도록 만들어졌습니다. code:

func StartController[T any](sender chan Packet[T]) {
    go runThread(sender)
}

func runThread[T any](sender chan Packet[T]) {
    fmt.Println("in thread")
    for true {
        data := <-sender
        fmt.Println(data)
    }
}

그러나 이 접근 방식에서는 제네릭 유형 Packet[T 인터페이스{}]의 인스턴스화 실패로 인해 컴파일 오류가 발생했습니다.

제네릭의 올바른 사용법 :

제네릭 사용의 전제는 매개변수화된 유형을 구체적인 유형 매개변수로 인스턴스화해야 한다는 것입니다. 용법. 예를 들어 제네릭 유형 GenericChan[T any] chan T에는 구체적인 유형을 사용한 명시적인 인스턴스화가 필요합니다.

c := make(GenericChan[int])

대체 솔루션:

제네릭을 사용하는 대신, 대체 솔루션은 인터페이스{} 유형을 사용하는 것입니다. 유형:

c := make(chan interface{})

func StartController(sender chan interface{}) {
    go runThread(sender)
}

func runThread(sender chan interface{}) {
    fmt.Println("in thread")
    for true {
        data := <-sender
        fmt.Println(data)
    }
}

이 접근 방식을 사용하면 채널이 모든 유형의 데이터를 수신할 수 있습니다. 그러나 실제 유형을 결정하기 위해 데이터 처리 중에 유형 어설션이 필요합니다.

인터페이스 사용의 단점{}:

인터페이스 사용{}은 유연성을 제공하지만 또한 잠재적인 단점이 있습니다.

• 유형 손실 안전성: 인터페이스{}는 유형 안전성을 잃어 잠재적으로 런타임 오류로 이어질 수 있습니다.
• 지저분한 논리: 유형 어설션의 필요성으로 인해 데이터 구문 분석 및 처리가 더욱 복잡해집니다.

결론:

그동안 제네릭은 장점을 제공하므로 올바른 사용법과 제한 사항을 이해하는 것이 중요합니다. 모든 유형을 처리할 수 있는 채널의 경우, 인터페이스를 사용하는 것은 유형 안전성과 코드 복잡성이 어느 정도 상충되기는 하지만 여전히 실행 가능한 솔루션입니다.

위 내용은 컴파일 오류 없이 다양한 런타임 유형에 대한 Go Generic 컨테이너를 어떻게 만들 수 있나요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!