std :: vector에서 상속하지 않아야합니다.

좋아, 이것은 고백하기가 정말로 어렵지만, 나는 지금부터 물려받을 강한 유혹을 받는다 std::vector.

벡터에 대해 약 10 개의 사용자 정의 알고리즘이 필요하며 벡터의 직접 멤버가되기를 바랍니다. 그러나 당연히 나는 나머지 std::vector인터페이스 를 원합니다 . 법을 준수하는 시민으로서의 첫 번째 아이디어 std::vector는 MyVector수업에 회원 을 두는 것이 었습니다 . 그러나 모든 std :: vector의 인터페이스를 수동으로 제공해야합니다. 입력하기에 너무 많습니다. 다음으로 개인 상속에 대해 생각했기 때문에 메서드를 제공하는 대신 using std::vector::member공개 섹션에 여러 개를 작성했습니다 . 실제로 너무 지루합니다.

그리고 여기에, 나는 실제로 공개적으로 상속 할 수 있다고 생각 std::vector하지만이 클래스를 다형성으로 사용해서는 안된다는 경고를 문서에 제공합니다. 나는 대부분의 개발자들이 이것이 다형성으로 사용되어서는 안된다는 것을 이해하기에 충분히 유능하다고 생각합니다.

내 결정이 절대적으로 정당하지 않습니까? 그렇다면 왜 그렇습니까? 추가 멤버가 실제로 멤버이지만 벡터의 모든 인터페이스를 다시 입력하지는 않는 대안을 제공 할 수 있습니까 ? 나는 그것을 의심하지만, 가능하다면 나는 행복 할 것이다.

또한 일부 바보는 다음과 같은 것을 쓸 수 있다는 사실을 제외하고

std::vector<int>* p  = new MyVector

MyVector를 사용할 때 다른 현실적인 위험이 있습니까? 사실이라고 말하면 벡터에 대한 포인터를 취하는 함수를 상상하는 것과 같은 것을 버립니다 ...

글쎄, 나는 나의 사건을 진술했다. 나는 죄를 지었다. 이제 나를 용서할지 아닌지는 당신에게 달려 있습니다 :)

사실,의 ​​상속 상속에는 아무런 문제가 없습니다 std::vector. 이것이 필요하면 그렇게하십시오.

정말로 필요한 경우에만 그렇게하는 것이 좋습니다 . 자유 기능으로 원하는 것을 수행 할 수없는 경우에만 (예 : 상태를 유지해야 함).

문제는 MyVector새로운 실체라는 것입니다. 그것은 새로운 C ++ 개발자가 그것을 사용하기 전에 지옥이 무엇인지 알아야한다는 것을 의미합니다. 차이 무엇 std::vector과 MyVector? 어느 쪽이 여기저기서 사용하는 것이 더 낫습니까? 내가 이동해야하는 경우 std::vector에 MyVector? 그냥 사용할 수 swap()있습니까?

더 좋아 보이는 것을 만들기 위해 새로운 엔티티를 만들지 마십시오. 이러한 실체들 (특히, 그런 것들)은 진공 상태에서 살지 않을 것입니다. 그들은 끊임없이 증가하는 엔트로피와 혼합 환경에서 살 것입니다.

전체 STL은 알고리즘과 컨테이너가 분리 되도록 설계되었습니다 .

이것은 const iterators, random access iterators 등과 같은 다른 유형의 반복자 개념으로 이어졌습니다.

따라서이 컨벤션을 수락 하고 작업중 인 컨테이너가 무엇인지 신경 쓰지 않는 방식으로 알고리즘을 설계 하는 것이 좋습니다. 그리고 수행 해야하는 특정 유형의 반복자 만 필요합니다. 작업.

또한 Jeff Attwood의 좋은 말로 안내해 드리겠습니다 .

std::vector공개적으로 상속받지 않는 주된 이유 는 가상 소멸자가 없기 때문에 자손의 다형 적 사용을 효과적으로 방지 할 수 있습니다. 특히,하는 수 없습니다 에 파생 객체 (파생 클래스에 구성원을 추가하지 않는 경우에도)에서 실제로 점, 아직 컴파일러는 일반적으로 대한 경고를 표시 할 수 없습니다.deletestd::vector<T>*

이러한 조건에서는 개인 상속이 허용됩니다. 따라서 아래에 표시된 것처럼 개인 상속을 사용하고 부모로부터 필요한 메소드를 전달하는 것이 좋습니다.

class AdVector: private std::vector<double>
{
    typedef double T;
    typedef std::vector<double> vector;
public:
    using vector::push_back;
    using vector::operator[];
    using vector::begin;
    using vector::end;
    AdVector operator*(const AdVector & ) const;
    AdVector operator+(const AdVector & ) const;
    AdVector();
    virtual ~AdVector();
};

먼저 대부분의 응답자가 지적한 것처럼 알고리즘을 리팩토링하여 작동하는 컨테이너 유형을 추상화하고 무료 템플릿 기능으로 남겨 두어야합니다. 이것은 일반적으로 알고리즘이 컨테이너 대신 인수로 반복자 쌍을 허용하도록하여 수행됩니다.

당신이 이것을 고려하고 있다면, 당신은 이미 당신의 사무실에서 언어 교육자들을 죽였다. 그들을 방해하지 않는 이유는 무엇입니까?

struct MyVector
{
   std::vector<Thingy> v;  // public!
   void func1( ... ) ; // and so on
}

그러면 실수로 MyVector 클래스를 업 캐스팅 할 때 발생할 수있는 모든 실수를 피할 수 있으며 조금만 추가하면 모든 벡터 작업에 계속 액세스 할 수 있습니다 .v.

무엇을 성취하기를 바라고 있습니까? 일부 기능 만 제공합니까?

이를 수행하는 C ++ 관용적 방법은 기능을 구현하는 일부 무료 기능을 작성하는 것입니다. 실제로 std :: vector가 필요하지 않을 가능성이 있습니다.실제로 구현하는 기능에 대해 . 이는 std :: vector에서 상속하려고하면 실제로 재사용 가능성을 잃고 있음을 의미합니다.

표준 라이브러리와 헤더를보고 작동 방식에 대해 묵상 할 것을 강력히 권합니다.

나는 거의 100 %의 맹목적으로 따라야 할 규칙이 거의 없다고 생각합니다. 당신이 그것에 대해 많은 생각을했던 것처럼 들리며, 이것이 갈 길이라고 확신합니다. 따라서 누군가 이렇게하지 말아야 할 특별한 이유가 없다면 계획을 진행해야한다고 생각합니다.

자신의 방식으로 정의 의 숨겨진 세부 사항을 처리하기 때문에 또는 다른 클래스 대신에 해당 클래스의 객체를 사용해야하는 이데올로기 적 이유가없는 한, std::vector다른 방식으로 작동하는 클래스를 만들지 않는 한 상속 할 이유가 없습니다. 의 것. 그러나 C ++에서 표준 작성자는 상속 된 클래스가 벡터를 특정 방식으로 향상시키기 위해 활용할 수있는 인터페이스 (보호 멤버의 형태)를 제공하지 않았습니다 . 실제로, 그들은 확장을 필요로하거나 추가 구현을 미세 조정할 필요가 있는 특정 측면 을 생각할 방법이 없었기 때문에 어떤 목적 으로든 그러한 인터페이스를 제공 할 필요가 없었습니다.std::vectorstd::vectorstd::vectorstd::vector

두 번째 옵션의 이유 std::vector는 다형성이 아니기 때문에 단지 이데올로기 일 수 있으며 , 그렇지 않으면 std::vector공개 상속을 통해 또는 공개 멤버십을 통해 공개 인터페이스를 노출하는지 여부에 차이가 없습니다 . (자유로운 기능을 피할 수 있도록 객체의 상태를 유지해야한다고 가정하십시오). 소리가 적고 이데올로기 적 관점에서 볼 때 std::vectors는 일종의 "간단한 아이디어"인 것처럼 보이며 , 대신 가능한 다른 클래스의 객체 형태의 복잡성은 이데올로기 적으로 사용하지 않습니다.

실질적인 용어 : 파생 클래스에 데이터 멤버가 없으면 다형성 사용법이 아니라도 아무런 문제가 없습니다. 기본 클래스와 파생 클래스의 크기가 다르거 나 가상 함수 (v- 테이블을 의미)가있는 경우 가상 소멸자 만 필요합니다.

BUT 이론 : C ++ 0x FCD의 [expr.delete]에서 : 첫 번째 대안 (객체 삭제)에서 삭제할 객체의 정적 유형이 동적 유형과 다른 경우 정적 유형은 삭제할 객체의 동적 유형의 기본 클래스이며 정적 유형은 가상 소멸자를 갖거나 동작이 정의되지 않습니다.

그러나 문제없이 std :: vector에서 개인적으로 파생 할 수 있습니다. 다음 패턴을 사용했습니다.

class PointVector : private std::vector<PointType>
{
    typedef std::vector<PointType> Vector;
    ...
    using Vector::at;
    using Vector::clear;
    using Vector::iterator;
    using Vector::const_iterator;
    using Vector::begin;
    using Vector::end;
    using Vector::cbegin;
    using Vector::cend;
    using Vector::crbegin;
    using Vector::crend;
    using Vector::empty;
    using Vector::size;
    using Vector::reserve;
    using Vector::operator[];
    using Vector::assign;
    using Vector::insert;
    using Vector::erase;
    using Vector::front;
    using Vector::back;
    using Vector::push_back;
    using Vector::pop_back;
    using Vector::resize;
    ...

좋은 C ++ 스타일을 따르는 경우 가상 함수가없는 것이 문제가 아니라 슬라이싱입니다 ( https://stackoverflow.com/a/14461532/877329 참조 ).

가상 기능이없는 것이 왜 문제가되지 않습니까? 함수는 delete소유권을 가지지 않기 때문에 함수가 받는 포인터를 시도해서는 안됩니다 . 따라서 엄격한 소유권 정책을 따르는 경우 가상 소멸자가 필요하지 않습니다. 예를 들어, 이것은 항상 가상 소멸자가 있거나 없거나 잘못된 것입니다.

void foo(SomeType* obj)
    {
    if(obj!=nullptr) //The function prototype only makes sense if parameter is optional
        {
        obj->doStuff();
        }
    delete obj;
    }

class SpecialSomeType:public SomeType
    {
    // whatever 
    };

int main()
    {
    SpecialSomeType obj;
    doStuff(&obj); //Will crash here. But caller does not know that
//  ...
    }

반대로, 이것은 항상 가상 소멸자가 있거나없는 상태에서 작동합니다.

void foo(SomeType* obj)
    {
    if(obj!=nullptr) //The function prototype only makes sense if parameter is optional
        {
        obj->doStuff();
        }
    }

class SpecialSomeType:public SomeType
    {
    // whatever 
    };

int main()
    {
    SpecialSomeType obj;
    doStuff(&obj);
//  The correct destructor *will* be called here.
    }

팩토리에서 오브젝트를 작성하는 경우 팩토리 delete는 자체 힙을 사용할 수 있으므로 작업 대신 삭제 포인터를 리턴해야합니다 . 호출자는 형식을 a share_ptr또는로 얻을 수 있습니다 unique_ptr. 즉,하지 않습니다 delete당신이하지 않은 것을 직접 으로부터를 new.

네, 안전하지 않은 일을하지 않도록 조심하는 한 안전합니다 ... 저는 누군가가 새로운 벡터를 사용하는 것을 본 적이 없기 때문에 실제로는 괜찮을 것입니다. 그러나 C ++의 일반적인 관용구는 아닙니다 ....

알고리즘이 무엇인지에 대한 자세한 정보를 제공 할 수 있습니까?

때로는 디자인으로 한 길을 가고 결국 다른 길을 볼 수 없습니다-10 개의 새로운 알고리즘으로 벡터를 만들어야한다고 주장하면 알람 벨이 울립니다. 벡터가 구현할 수있는 알고리즘 또는 범용 벡터이며 응용 프로그램 별 함수를 포함하는 객체를 만들려고합니까?

나는 당신이 이것을해서는 안된다는 것을 말하고있는 것이 아닙니다. 알람 벨에 주어진 정보가 울리면 추상화에 문제가 있다고 생각하게하고 필요.

나는 또한 std::vector최근 부터 물려 받았으며 매우 유용하다는 것을 알았으며 지금까지 아무런 문제가 없었습니다.

내 클래스는 희소 행렬 클래스이므로 행렬 요소를 어딘가, 즉에 저장해야합니다 std::vector. 상속 한 이유는 모든 메소드에 대한 인터페이스를 작성하기에는 너무 게으르고 SWIG를 통해 Python에 클래스를 인터페이스하는 것입니다. 이미 좋은 인터페이스 코드가 std::vector있습니다. 이 인터페이스 코드를 처음부터 새로 작성하지 않고 클래스로 확장하는 것이 훨씬 쉽다는 것을 알았습니다.

나는 접근 방식을 볼 수있는 유일한 문제는 너무 많은 비 가상 소멸자로이 아니라 같은 내가 과부하에하고 싶은 몇 가지 다른 방법,, push_back(), resize(),insert() 등 개인 상속은 참으로 좋은 옵션이 될 수 있습니다.

감사!

여기에 원하는 두 가지 방법을 더 소개하겠습니다. 하나는 포장하는 또 다른 방법 std::vector이며, 다른 하나는 사용자에게 아무것도 부술 수있는 기회를주지 않고 상속하는 방법입니다.

1. std::vector많은 함수 래퍼를 작성하지 않고 다른 래핑 방법을 추가하겠습니다 .

#include <utility> // For std:: forward
struct Derived: protected std::vector<T> {
    // Anything...
    using underlying_t = std::vector<T>;

    auto* get_underlying() noexcept
    {
        return static_cast<underlying_t*>(this);
    }
    auto* get_underlying() const noexcept
    {
        return static_cast<underlying_t*>(this);
    }

    template <class Ret, class ...Args>
    auto apply_to_underlying_class(Ret (*underlying_t::member_f)(Args...), Args &&...args)
    {
        return (get_underlying()->*member_f)(std::forward<Args>(args)...);
    }
};

2. dtor 문제 대신 std :: span 에서 상속 std::vector하고 dtor 문제를 피하십시오.

이 질문은 숨을 쉬지 않는 진주 클러치를 만들어내는 것이 보장되지만 실제로 표준 컨테이너에서 파생되는 것을 피하기 위해 또는 "불필요하게 개체를 곱하는"피할만한 이유는 없습니다. 가장 단순하고 짧은 표현이 가장 명확하고 가장 좋습니다.

파생 된 유형에 대해 모든 일반적인주의를 기울여야하지만 표준의 기준에 대해서는 특별한 것이 없습니다. 기본 멤버 함수를 재정의하는 것은 까다로울 수 있지만 가상이 아닌 기본과는 현명하지 않으므로 여기에는 특별한 것이 없습니다. 데이터 멤버를 추가하려는 경우 멤버가베이스의 컨텐츠와 일관성을 유지해야하는 경우 슬라이싱에 대해 걱정해야하지만 다시는베이스와 동일합니다.

표준 컨테이너에서 파생 된 것으로 특히 유용한 곳은 다른 생성자에 의해 혼란이나 납치의 가능성없이 필요한 초기화를 정확하게 수행하는 단일 생성자를 추가하는 것입니다. (나는 당신을 찾고 있습니다, initialize_list 생성자!) 그런 다음 결과 객체를 자유롭게 사용할 수 있습니다. 템플릿 인수를 파생 클래스에 바인딩하는 것을 방해하지 않는 한 걱정할 필요가 없습니다.

이 기술이 C ++ 20에서 즉시 유용한 곳은 예약입니다. 우리가 쓴 곳

  std::vector<T> names; names.reserve(1000);

우리는 말할 수있다

  template<typename C> 
  struct reserve_in : C { 
    reserve_in(std::size_t n) { this->reserve(n); }
  };

그리고 반원으로서도

  . . .
  reserve_in<std::vector<T>> taken_names{1000};  // 1
  std::vector<T> given_names{reserve_in<std::vector<T>>{1000}}; // 2
  . . .

(기본 설정에 따라) 그리고 reserve ()를 호출하기 위해 생성자를 작성할 필요가 없습니다.

( reserve_in기술적으로 C ++ 20을 기다려야 하는 이유 는 이전 표준에서 이동 중에 빈 벡터의 용량을 보존 할 필요가 없기 때문입니다. 감독으로 인정되고 합리적으로 수정 될 수 있습니다 우리는 또한 기존의 모든 구현이 실제로 이동에 걸쳐 용량을 보존하기 때문에 표준이 요구하지 않았기 때문에 수정 사항이 효과적으로 이전 표준으로 업데이트 될 것으로 예상 할 수 있습니다. 총-예약은 거의 항상 최적화입니다.)

어떤 사람들은 reserve_in 무료 함수 템플릿 가 더 낫다고 .

  template<typename C> 
  auto reserve_in(std::size_t n) { C c; c.reserve(n); return c; }

이러한 대안은 확실히 실행 가능하며 * RVO로 인해 때로는 훨씬 더 빠를 수도 있습니다. 그러나 파생 또는 자유 기능의 선택은 표준 구성 요소에서 파생되는 데 대한 기본이 아닌 미신이 아닌 자체 장점으로 이루어져야합니다. 위의 예제 사용에서 두 번째 형식 만 free 기능으로 작동합니다. 클래스 컨텍스트 외부에서 조금 더 간결하게 작성할 수 있습니다.

  auto given_names{reserve_in<std::vector<T>>(1000)}; // 2