Rust는 구조체의 필드나 배열의 요소로 사용되는 모든 타입이 Sized 특성을 구현하도록 요구하여 컴파일러가 컴파일 시간에 고정된 메모리 오프셋과 스택 프레임 레이아웃을 계산할 수 있도록 보장합니다. dyn Trait 구성은 본질적으로 !Sized(크기가 정해지지 않음)인 동적으로 배포되는 트레이트 객체를 나타내며, 이는 인터페이스 뒤의 구체적 타입이 지워져 다양한 메모리 크기를 갖는 구현이 동일한 추상 타입을 차지할 수 있도록 합니다. Rust는 dyn Trait을 데이터 포인터와 메서드 주소 및 소멸자 정보를 담고 있는 vtable 포인터를 포함하는 두 개 단어 구조체인 fat pointer로 나타내어 동적 분배를 지원하지만, 타입 자체는 여전히 크기가 정해지지 않았기 때문에 포인티의 크기는 알 수 없습니다. 따라서 dyn Trait를 직접 인라인으로 포함하면 Sized 한계에 위배되며, 컴파일러는 구조체의 경계나 배열의 보폭을 결정할 수 없으므로, fat pointer를 Sized 컨테이너 내에 감싸기 위해 Box, Rc, Arc 또는 참조 **&**를 통해 간접적으로 처리해야 합니다.
당신은 게임 엔진을 위한 플러그인 아키텍처를 설계하고 있으며, 모더들이 단순 정수 플래그를 저장하는 경우와 큰 공간 해시 그리드를 유지하는 다른 경우를 포함하여 다양한 구현을 제공하는 Behavior 특성을 제공하고 있습니다. 게임 엔진은 GameState 구조체에서 활성 행동의 컬렉션을 유지해야 합니다.
struct GameState { behaviors: Vec<dyn Behavior> }를 정의하려고 하면 dyn Behavior가 컴파일 시간에 알려진 상수 크기를 가지고 있지 않다는 오류로 인해 즉시 컴파일이 실패합니다.
고려된 한 가지 해결책은 포인터 자체에 대한 힙 할당을 피하기 위해 Vec<&dyn Behavior>를 사용하여 빌려진 트레이트 객체를 저장하는 것이 었습니다. 이 접근 방식은 모든 플러그인 데이터가 적어도 GameState만큼 오래 지속되어야 하는 엄격한 생존 주기를 impose하며, 플러그인이 동적으로 언로드되는 핫 리로딩 시나리오를 복잡하게 만들어 수정 가능한 엔진에는 너무 제한적이라는 것이 입증되었습니다.
평가된 또 다른 대안은 모든 알려진 구현을 래핑하는 enum BehaviorType { Ai(AiModule), Physics(PhysicsBody) }을 정의하여 열거형 배포를 사용하는 것이 었습니다. 이것은 정적 분배 및 훌륭한 캐시 지역성을 제공하지만, 엔진의 핵심 수정을 요구하는 폐쇄 세트를 만들며, 개방/폐쇄 원칙을 위배하고 엔진을 다시 컴파일하지 않고는 서드파티 바이너리 확장을 방지합니다.
선택된 해결책은 각 행동 인스턴스를 힙 할당하고 결과 fat pointer를 벡터에 저장하기 위해 Vec<Box<dyn Behavior>>를 사용하는 것이 었습니다. 이것은 Box 간접 처리를 통해 Sized 요구를 충족하면서 런타임 다형성을 유지하고 이종 컬렉션을 허용했지만, 작은 행동 구성 요소를 위한 사용자 정의 아레나 할당기를 통해 완화된 예측 가능한 힙 단편화 비용이 발생했습니다.
CoerceUnsized가 Box<T>를 Box<dyn Trait>로 변환할 때 런타임에 새 vtable을 할당하지 않고 어떻게 가능하게 하며, 포인티에 어떤 메모리 레이아웃 제약이 발생합니까?
CoerceUnsized는 Box, Rc, Arc와 같은 스마트 포인터에 의해 구현된 마커 특성으로, 크기가 정해지지 않은 강제를 허용합니다. Box<Concrete>를 Box<dyn Trait>로 변환할 때, 컴파일러는 Trait를 구현하는 Concrete에 대한 vtable을 컴파일 시간에 정적으로 생성하고, 이진 파일의 읽기 전용 섹션에 포함됩니다. 변환은 포인터 메타데이터를 단순히 재해석하며, 얇은 포인터(단일 단어)에서 fat pointer(데이터 주소 + vtable 주소)로 폭을 넓히고, 기본 데이터를 이동하거나 런타임에서 메모리를 할당하지 않습니다. 이는 구체적 타입이 트레이트 객체의 예상 표현과 호환 가능한 메모리 레이아웃을 가져야 한다는 엄격한 제약을 부여합니다. 즉, 데이터 포인터는 vtable이 필드를 기대하는 객체의 시작에 정렬되어야 하며, 타입은 #[repr(Rust)] 또는 호환 가능한 표현 보장을 준수해야 하며, 이는 vtable에서 메서드 오프셋이 구체적 구현의 함수로 올바르게 해결되도록 보장합니다.
왜 Rust는 값을 소비하는 메서드가 정의된 특성(dyn Trait)으로부터 트레이트 객체를 생성하는 것을 금지하고, 이것이 함수 반환 타입에 대한 Sized 요구와 어떻게 관련됩니까?
이 금지는 객체 안전성 규칙에서 유래합니다. 메서드가 값을 소비할 때, 컴파일러는 값을 이동할 정확한 스택 프레임을 생성하고 정확한 메모리 오프셋에 올바른 소멸자 호출을 삽입하기 위해 구체적 타입의 정확한 크기를 알아야 합니다. dyn Trait 컨텍스트에서는 구체적 타입이 지워지므로, vtable에는 크기와 드롭 정보가 포함되지만, 호출자의 스택 프레임은 이동된 값의 알 수 없는 크기를 수용하도록 동적으로 조정될 수 없습니다. 더욱이 Self를 반환하는 메서드는 호출자가 알 수 없는 크기의 반환 슬롯 공간을 할당해야 하므로, 스택 손상 및 정의되지 않은 동작을 방지하기 위해 Rust는 값에 의한 self 메서드가 있는 특성에 대한 트레이트 객체 생성을 금지하여 모든 상호작용이 간접성을 통해 이루어지도록 보장합니다(&self 또는 &mut self), 이러한 경우 포인터 크기는 일정합니다.
Trait가 Send을 슈퍼트레이트로 가질 때 dyn Trait이 자동으로 Send을 구현하는 것과 dyn Trait + Send을 명시적으로 주석 처리하는 것의 차이점은 무엇이며, 둘 중 어느 것도 없으면 트레이트 객체가 Send이 구현된 기초 구체적 타입에 대해 스레드 안전성 검사를 통과하지 못하는 이유는 무엇입니까?
Trait가 슈퍼트레이트로 Send를 선언할 경우(예: trait Trait: Send {}), 컴파일러는 이 제약을 전파하여 모든 구현자가 반드시 Send가 되어야 하므로 dyn Trait에 대해 자동으로 Send를 구현하게 됩니다. 반면에 Trait에 이 슈퍼트레이트가 없는 경우, dyn Trait + Send를 작성하면 두 가지를 모두 구현하는 구체적 타입만을 허용하는 트레이트 객체가 생성되므로 변환 프로세스에서 허용되는 타입을 좁힙니다. 슈퍼트레이트도 명시적 제약도 모두 없으면, dyn Trait는 포인터 뒤에 있는 구체적 인스턴스가 스레드 안전하더라도 Send를 구현하지 않는데, 이는 타입 지워짐이 이 정보를 삭제하기 때문입니다. 컴파일러는 모든 가능한 타입이 해당 vtable 슬롯을 차지할 수 있다는 것을 보장할 수 없습니다. 이는 스레드 경계를 넘어 스레드 안전하지 않은 타입의 우발적인 전송을 방지합니다.