C STL 컨테이너를 상속해야 할까요?

C STL 컨테이너에서 파생할 때 발생할 수 있는 위험

C 표준 라이브러리(STL) 컨테이너에서 파생하는 관행은 다음과 같은 주제였습니다. 논쟁이 벌어지고 있으며, 일부에서는 그 사용에 반대하고 있습니다. 함수 오버로드 및 전문화 활성화와 같은 장점이 있다고 인식됨에도 불구하고 이 접근 방식에는 잠재적인 위험이 있습니다.

STL 컨테이너에 가상 소멸자가 없으면 심각한 위험이 따릅니다. 가상 소멸자가 없는 STL 컨테이너에서 클래스를 파생하는 경우 파생 클래스가 다형성 동작을 제대로 처리하지 못할 수 있습니다. 이로 인해 특히 파생 클래스의 개체가 컨테이너에 저장되고 기본 클래스 포인터를 통해 액세스되는 경우 예상치 못한 결과가 발생할 수 있습니다.

설명하려면 다음 시나리오를 고려하세요.

#include <vector>

void kill_it(std::vector<double> *victim) {
    delete victim; // Invokes non-virtual ~std::vector<>()
}

typedef std::vector<double> Rates;
class Charges: public std::vector<double> { };

int main() {
    std::vector<double> *p1, *p2;
    p1 = new Rates;
    p2 = new Charges;
    
    // Possible error introduced by user code
    kill_it(p2);
    kill_it(p1);
    
    return 0;
}

이 예에서는 , kill_it 함수는 파생 클래스 Charges에 대한 지식이 없습니다. 결과적으로 기본 클래스 std::벡터의 가상이 아닌 소멸자를 호출하게 되며, 이는 Charges 유형의 객체를 삭제할 때 정의되지 않은 동작으로 이어질 수 있습니다. Rates에서 볼 수 있듯이 Charges가 유형 별칭 또는 typedef로 구현된 경우에는 이 동작이 발생하지 않습니다.

STL 컨테이너에서 파생할 때 발생하는 또 다른 잠재적인 문제는 Microsoft의 벡터 클래스 구현에서 발생합니다. 이 구현에서 벡터 클래스 자체는 상속을 통해 구현됩니다. _Vector_Val<>에서 공개적으로 파생됩니다. 이로 인해 파생 클래스로 작업할 때 복잡성과 잠재적인 위험이 추가됩니다.

특정 시나리오에서는 상속을 사용하면 이점이 있을 수 있지만 복잡성이 증가하고 잠재적인 위험이 따르는 경우가 많습니다. 기본 클래스가 아닌 멤버 변수로 컨테이너를 사용하는 구성은 일반적으로 명확성을 위해 선호되고 파생과 관련된 잠재적인 문제를 피하기 위해 선호됩니다.

위 내용은 C STL 컨테이너를 상속해야 할까요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!