지도에서 구조체에 대한 Go 포인터를 인쇄하면 구조체 값 대신 주소가 표시되는 이유는 무엇입니까?

Go 포인터의 뉘앙스 이해

Go에서는 포인터의 미묘함을 파악하는 것이 효과적인 프로그래밍에 중요합니다. 이 기사에서는 맵에 저장되고 포인터로 인쇄된 값이 예상치 못한 결과를 낳는 특정 시나리오를 자세히 살펴봅니다.

문제: 수수께끼 풀기

Go 프로그램 GORM First() 함수와 함께 사용하도록 지정된 구조체 값(Test)을 포함하는 키-값 쌍을 포함하는 맵(모델)과 함께 작동합니다. 맵에서 구조체를 검색하고 포인터로 인쇄하려고 할 때 수수께끼 같은 동작이 발생합니다. GORM 함수에는 구조체가 필요하지만 인쇄 작업에서는 단순한 주소인 것처럼 보이는 출력이 생성됩니다.

해결책: 미스터리 풀기

핵심은 다음에 있습니다. fmt 패키지의 기본 형식의 복잡성을 탐구합니다. 형식을 지정하지 않고 값을 인쇄할 때 fmt.Printf()는 값 유형을 기반으로 하는 기본 규칙을 사용합니다. 초기 예에서 test1은 Test 유형이고 인쇄 함수에 대한 포인터로 전달됩니다. 기본 형식에 따르면 구조체에 대한 포인터는 &{field0 field1 ...}으로 표시되며, 이는 Test 필드가 "a"로 초기화될 때 &{a}의 모양을 설명합니다.

그러나 두 번째 예에는 미묘한 차이가 있습니다. 모델 맵에서 검색된 값(test2)은 맵의 유형 선언(map[string]interface{})으로 인해 인터페이스{} 유형입니다. test2에 대한 포인터를 인쇄하려고 하면 값이 기본적으로 추가 인터페이스{} 값으로 래핑되어 *인터페이스{} 유형이 됩니다. *인터페이스{} 값의 기본 형식은 주소 인쇄를 지시하므로 관찰된 16진수 주소 값이 출력됩니다.

딜레마 해결: 보다 우아한 접근 방식

효과적으로 test2에서 원하는 구조체를 추출하면 유형 어설션을 사용할 수 있습니다. 여기에는 인터페이스 값을 의도한 유형(이 경우 Test)으로 명시적으로 캐스팅하는 작업이 포함됩니다. 이렇게 하면 test2 값의 유형이 test1과 동일해 인쇄 시 일관된 출력이 생성됩니다.

또는 더 최적의 솔루션은 테스트 값에 대한 포인터를 모델 맵에 직접 저장하여 유형 주장 또는 중간 변수 할당. 이렇게 하면 맵의 인터페이스{} 값이 본질적으로 테스트에 대한 포인터이며 직접 사용하거나 전송할 준비가 됩니다.

Go 개발의 미묘한 차이를 탐색하려면 Go의 포인터 동작과 기본 형식을 이해하는 것이 필수적입니다. 환경. 프로그래머는 이러한 개념을 이해함으로써 Go 기능의 잠재력을 최대한 활용하는 우아하고 효율적인 코드를 작성할 수 있습니다.

위 내용은 지도에서 구조체에 대한 Go 포인터를 인쇄하면 구조체 값 대신 주소가 표시되는 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!