비호환성은 std::uses_allocator 타입 특성에서 기인하며, 이는 std::string과 std::pmr::polymorphic_allocator 조합에 대해 false로 평가됩니다. std::string은 allocator_type을 **std::allocator<char>**로 하드코딩 하는 반면, std::pmr::vector는 **std::pmr::polymorphic_allocator<char>**를 제공합니다. 이들은 묵시적 변환이나 상속 관계가 없는 구별된 클래스 유형입니다. 컨테이너가 요소를 생성할 때, 할당자를 생성자 인자로 전달할지 여부를 결정하기 위해 **std::uses_allocator_v<T, Alloc>**를 쿼리합니다. 이 체크가 실패하므로, 벡터는 std::string을 할당자를 인식하지 못하는 것으로 간주하고 기본 생성자를 호출하며, 이는 벡터의 메모리 리소스와 상관없이 전역 new 및 delete를 내부적으로 사용합니다.
static_assert(!std::uses_allocator_v<std::string, std::pmr::polymorphic_allocator<char>>); // std::pmr::vector는 std::string에 할당자를 전달하지 않음
금융 위험 계산 엔진을 최적화하는 과정에서, 우리는 힙 경합을 피하기 위해 스택 메모리로 지원되는 std::pmr::monotonic_buffer_resource를 사용하는 핫 경로로 리팩토링했습니다. 모든 임시 기호 이름이 단조 버퍼에서 추출되기를 기대하며 std::pmr::vectorstd::string temp_symbols를 선언했으나, 성능 프로파일링 결과 std::string 생성자 내에서 예기치 않은 malloc 호출이 발생하여 메모리 리소스가 완전히 우회되고 있음을 확인했습니다.
우리는 모든 std::string을 명시적인 std::pmr::polymorphic_allocator를 생성자에 전달하여 수동으로 생성하는 것을 고려했으나, 이는 고수준 비즈니스 로직에 할당 세부사항을 노출하게 되어 emplace_back과 같은 편리한 수식어의 사용을 방해했습니다. 또 다른 접근은 std::string에서 상속받고 다형적 할당기를 허용하는 사용자 정의 문자열 래퍼를 생성하는 것이었지만, 이는 리스코프 치환 원칙을 위반하고 컨테이너 재할당 과정에서 객체 슬라이싱 위험을 초래했습니다. 결국 우리는 std::string을 std::pmr::string(즉, **std::basic_string<char, std::char_traits<char>, std::pmr::polymorphic_allocator<char>**의 별칭)으로 대체하였고, 이는 본질적으로 allocator_type을 다형적 변형으로 선언합니다. 이를 통해 벡터는 uses_allocator 프로토콜을 통해 할당자를 자동으로 전파하게 되었고, 핫 경로에서 모든 힙 할당을 제거하여 지연 시간을 마이크로초에서 수백 나노초로 줄일 수 있었습니다.
내부 동적 할당을 수행하는 사용자 정의 클래스를 어떻게 std::pmr::polymorphic_allocator와 호환되도록 만들 수 있나요? 단순히 생성자에서 할당기 매개변수를 수용하는 것만으로는 충분하지 않습니까?
클래스는 할당자 인식 여부를 공개 allocator_type 타입 별칭을 통해, 또는 첫 번째 매개변수가 std::allocator_arg_t이고 두 번째 매개변수가 할당기 타입인 생성자를 제공하며, **std::uses_allocator<ClassName, Alloc>**를 std::true_type에서 파생되도록 특수화하는 방식으로 명시적으로 광고해야 합니다. 이 광고 없이 std::pmr::vector는 클래스를 할당자를 인식하지 않는 것으로 가정하고 기본 초기화를 통해 생성하므로, 내부 할당이 다형적 메모리 리소스를 우회하게 됩니다.
**왜 **std::allocator_traits<std::pmr::polymorphic_allocator<T>>::rebind_alloc<U>가 std::pmr::vector와 std::string 간의 비호환성을 해결하지 못하나요?
재결합은 **std::pmr::polymorphic_allocator<U>**를 생성하지만, 이는 **std::allocator<U>**와 여전히 비호환합니다. 왜냐하면 두 유형은 서로 구별되는 구체적 유형으로 변환 관계가 없기 때문입니다. std::uses_allocator 메커니즘은 요소의 allocator_type이 컨테이너 할당기의 타입과 같거나 변환 가능해야 하며, 단순히 다른 값 타입으로 재결합할 수 있어서는 안 됩니다. std::string은 std::allocator를 하드코딩하므로, 컨테이너의 할당기를 재결합하더라도 요소가 기대하는 할당기 타입이 변경되지 않습니다.
왜 std::pmr::monotonic_buffer_resource를 std::pmr::string과 함께 사용할 때 특정 생명 주기 위험이 발생하며, 이 위험을 표준 할당기보다 감지하기 어려운 이유는 무엇인가요?
std::pmr::polymorphic_allocator는 타입 소거되며 기본 std::pmr::memory_resource에 대한 포인터를 저장하기 때문에, 컴파일 시간에 생명 주기 제약을 강제할 수 없습니다. 스택 기반 monotonic_buffer_resource를 참조하는 std::pmr::string이 더 긴 생명 주기를 가진 범위로 이동되거나 복사될 때, 메모리 리소스에 대한 포인터는 손상됩니다. 전역 힙(항상 유효함)으로 일반적으로 사용되는 std::allocator와 달리, 버퍼가 파기된 후 문자열에 접근하는 것은 유효하지 않은 메모리 접근을 초래합니다. 정적 분석기는 가상 do_allocate/do_deallocate 인터페이스가 타입 시스템에서 기저 리소스의 생명 주기를 숨기기 때문에 이를 감지하는 데 어려움을 겪습니다.