Jangan mewarisi dari std :: vector

Ok, ini benar-benar sulit untuk diakui, tetapi saya memiliki godaan yang kuat saat ini untuk diwarisi std::vector.

Saya membutuhkan sekitar 10 algoritma yang disesuaikan untuk vektor dan saya ingin mereka menjadi anggota vektor secara langsung. Tapi tentu saja saya juga ingin memiliki std::vectorantarmuka yang lain. Nah, ide pertama saya, sebagai warga negara yang taat hukum, adalah memiliki std::vectoranggota di MyVectorkelas. Tapi kemudian saya harus secara manual memberikan kembali semua antarmuka std :: vector. Terlalu banyak mengetik. Selanjutnya, saya berpikir tentang warisan pribadi, sehingga alih-alih memberikan kembali metode saya akan menulis banyak using std::vector::memberdi bagian publik. Ini membosankan sebenarnya juga.

Dan di sinilah saya, saya benar-benar berpikir bahwa saya dapat mewarisi dari publik std::vector, tetapi memberikan peringatan dalam dokumentasi bahwa kelas ini tidak boleh digunakan secara polimorfik. Saya pikir sebagian besar pengembang cukup kompeten untuk memahami bahwa ini seharusnya tidak digunakan secara polimorfik.

Apakah keputusan saya benar-benar tidak dapat dibenarkan? Jika demikian, mengapa? Bisakah Anda memberikan alternatif yang akan membuat anggota tambahan benar-benar anggota tetapi tidak akan melibatkan mengetik ulang semua antarmuka vektor? Saya meragukannya, tetapi jika Anda bisa, saya hanya akan bahagia.

Juga, terlepas dari kenyataan bahwa beberapa orang idiot dapat menulis sesuatu seperti

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

apakah ada bahaya realistis lain dalam menggunakan MyVector? Dengan mengatakan realistis saya membuang hal-hal seperti bayangkan fungsi yang mengambil pointer ke vektor ...

Yah, saya sudah menyatakan kasus saya. Saya telah berdosa. Sekarang terserah Anda untuk memaafkan saya atau tidak :)

Sebenarnya, tidak ada yang salah dengan warisan publik std::vector. Jika Anda membutuhkan ini, lakukan saja.

Saya sarankan melakukan itu hanya jika itu benar - benar diperlukan. Hanya jika Anda tidak dapat melakukan apa yang Anda inginkan dengan fungsi bebas (mis. Harus mempertahankan beberapa keadaan).

Masalahnya adalah MyVector adalah entitas baru. Ini berarti pengembang C ++ baru harus tahu apa itu sebelum menggunakannya. Apa perbedaan antara std::vectordan MyVector? Mana yang lebih baik untuk digunakan di sana-sini? Bagaimana jika saya harus pindah std::vectorke MyVector? Bolehkah saya menggunakan swap()atau tidak?

Jangan menghasilkan entitas baru hanya untuk membuat sesuatu terlihat lebih baik. Entitas-entitas ini (terutama, umum seperti itu) tidak akan hidup dalam kekosongan. Mereka akan hidup dalam lingkungan campuran dengan entropi yang terus meningkat.

Seluruh STL dirancang sedemikian rupa sehingga algoritma dan wadah terpisah .

Ini mengarah pada konsep berbagai jenis iterator: const iterators, iterators akses acak, dll.

Karena itu saya sarankan Anda untuk menerima konvensi ini dan merancang algoritma Anda sedemikian rupa sehingga mereka tidak akan peduli tentang wadah apa yang sedang mereka kerjakan - dan mereka hanya akan memerlukan jenis iterator tertentu yang mereka perlukan untuk menjalankannya. operasi.

Juga, izinkan saya mengarahkan Anda ke beberapa komentar baik oleh Jeff Attwood .

Alasan utama untuk tidak mewarisi dari std::vectorpublik adalah tidak adanya penghancur virtual yang secara efektif mencegah Anda dari penggunaan keturunan secara polimorfik. Secara khusus, Anda tidak diperbolehkan untuk deletesuatustd::vector<T>* yang benar-benar poin pada objek yang diturunkan (bahkan jika kelas turunan menambahkan tidak ada anggota), namun compiler umumnya tidak dapat memperingatkan Anda tentang hal itu.

Warisan pribadi diizinkan dalam kondisi ini. Karena itu saya sarankan menggunakan warisan pribadi dan meneruskan metode yang diperlukan dari orang tua seperti yang ditunjukkan di bawah ini.

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();
};

Pertama-tama Anda harus mempertimbangkan refactoring algoritma Anda untuk abstrak jenis wadah mereka beroperasi dan biarkan mereka sebagai fungsi templated gratis, seperti yang ditunjukkan oleh sebagian besar penjawab. Ini biasanya dilakukan dengan membuat suatu algoritma menerima sepasang iterator alih-alih wadah sebagai argumen.

Jika Anda mempertimbangkan hal ini, Anda jelas telah membunuh pedant bahasa di kantor Anda. Dengan mereka keluar dari jalan, mengapa tidak lakukan saja

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

Itu akan menghindari semua kesalahan yang mungkin terjadi yang secara tidak sengaja menyebarkan kelas MyVector Anda, dan Anda masih dapat mengakses semua ops vektor hanya dengan menambahkan sedikit .v.

Apa yang ingin kamu capai? Hanya menyediakan beberapa fungsionalitas?

Cara C ++ idiomatis untuk melakukan ini adalah dengan hanya menulis beberapa fungsi gratis yang mengimplementasikan fungsi tersebut. Kemungkinannya adalah Anda tidak benar-benar memerlukan std :: vector, khusus untuk fungsionalitas yang Anda laksanakan, yang berarti Anda benar-benar kehilangan reusability dengan mencoba mewarisi dari std :: vector.

Saya akan sangat menyarankan Anda untuk melihat perpustakaan dan header standar, dan merenungkan bagaimana mereka bekerja.

Saya pikir sangat sedikit aturan yang harus diikuti secara membabi buta 100% dari waktu. Sepertinya Anda sudah banyak berpikir, dan yakin bahwa inilah jalan yang harus ditempuh. Jadi - kecuali seseorang datang dengan alasan spesifik yang bagus untuk tidak melakukan ini - saya pikir Anda harus melanjutkan rencana Anda.

Tidak ada alasan untuk mewarisi dari std::vectorkecuali seseorang ingin membuat kelas yang bekerja berbeda dari std::vector, karena ia menangani dengan caranya sendiri rincian tersembunyi dari std::vectordefinisi, atau kecuali seseorang memiliki alasan ideologis untuk menggunakan objek dari kelas tersebut sebagai pengganti std::vectorYang itu. Namun, pencipta standar pada C ++ tidak menyediakan std::vectorantarmuka apa pun (dalam bentuk anggota yang dilindungi) yang dapat diwariskan oleh kelas yang diwariskan untuk meningkatkan vektor dengan cara tertentu. Memang, mereka tidak memiliki cara untuk memikirkan aspek tertentu yang mungkin perlu ekstensi atau menyempurnakan implementasi tambahan, sehingga mereka tidak perlu berpikir untuk menyediakan antarmuka semacam itu untuk tujuan apa pun.

Alasan untuk opsi kedua hanya bisa ideologis, karena std::vectorbukan polimorfik, dan jika tidak, tidak ada perbedaan apakah Anda mengekspos std::vectorantarmuka publik melalui warisan publik atau melalui keanggotaan publik. (Misalkan Anda perlu menyimpan beberapa status di objek Anda sehingga Anda tidak bisa lolos dengan fungsi bebas). Pada nada yang kurang terdengar dan dari sudut pandang ideologis, tampak bahwa std::vectors adalah semacam "ide sederhana", sehingga setiap kompleksitas dalam bentuk objek dari berbagai kelas yang mungkin di tempat mereka secara ideologis tidak digunakan.

Dalam istilah praktis: Jika Anda tidak memiliki anggota data di kelas turunan Anda, Anda tidak memiliki masalah, bahkan dalam penggunaan polimorfik. Anda hanya perlu destruktor virtual jika ukuran kelas dasar dan kelas turunan berbeda dan / atau Anda memiliki fungsi virtual (yang berarti tabel-v).

TETAPI dalam teori: Dari [expr.delete] dalam C ++ 0x FCD: Pada alternatif pertama (hapus objek), jika tipe statis objek yang akan dihapus berbeda dari tipe dinamisnya, tipe statis akan menjadi kelas dasar dari tipe dinamis dari objek yang akan dihapus dan tipe statis harus memiliki destruktor virtual atau perilaku tidak terdefinisi.

Tetapi Anda dapat memperoleh secara pribadi dari std :: vector tanpa masalah. Saya telah menggunakan pola berikut:

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;
    ...

Jika Anda mengikuti gaya C ++ yang baik, tidak adanya fungsi virtual bukanlah masalahnya, tetapi mengiris (lihat https://stackoverflow.com/a/14461532/877329 )

Mengapa tidak adanya fungsi virtual bukan masalah? Karena suatu fungsi tidak boleh mencoba ke deletepointer apa pun yang diterimanya, karena ia tidak memiliki kepemilikan terhadapnya. Oleh karena itu, jika mengikuti kebijakan kepemilikan yang ketat, penghancur virtual tidak diperlukan. Misalnya, ini selalu salah (dengan atau tanpa destruktor virtual):

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
//  ...
    }

Sebaliknya, ini akan selalu berhasil (dengan atau tanpa destruktor virtual):

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.
    }

Jika objek dibuat oleh pabrik, pabrik juga harus mengembalikan pointer ke deleter yang berfungsi, yang seharusnya digunakan sebagai ganti delete, karena pabrik dapat menggunakan tumpukannya sendiri. Penelepon bisa mendapatkannya dalam bentuk share_ptratau unique_ptr. Singkatnya, jangan lakukan deleteapa pun yang tidak Anda dapatkan langsung dari new.

Ya itu aman selama Anda berhati-hati untuk tidak melakukan hal-hal yang tidak aman ... Saya tidak berpikir saya pernah melihat orang menggunakan vektor dengan yang baru sehingga dalam praktiknya Anda mungkin akan baik-baik saja. Namun, itu bukan idiom umum dalam c ++ ....

Apakah Anda dapat memberikan informasi lebih lanjut tentang apa algoritma itu?

Kadang-kadang Anda akhirnya turun satu jalan dengan desain dan kemudian tidak dapat melihat jalur lain yang mungkin Anda ambil - fakta bahwa Anda mengklaim perlu vektor dengan 10 algoritma baru membunyikan lonceng alarm untuk saya - apakah benar-benar ada 10 tujuan umum algoritma yang dapat diimplementasikan oleh vektor, atau Anda mencoba membuat objek yang merupakan vektor tujuan umum DAN yang berisi fungsi spesifik aplikasi?

Saya tentu tidak mengatakan bahwa Anda tidak boleh melakukan ini, hanya saja dengan informasi yang Anda berikan bel alarm berdering yang membuat saya berpikir bahwa mungkin ada sesuatu yang salah dengan abstraksi Anda dan ada cara yang lebih baik untuk mencapai apa yang Anda ingin.

Saya juga mewarisi dari std::vectorbaru-baru ini, dan menemukan itu sangat berguna dan sejauh ini saya belum mengalami masalah dengannya.

Kelas saya adalah kelas matriks jarang, yang berarti bahwa saya perlu menyimpan elemen matriks saya di suatu tempat, yaitu dalam std::vector. Alasan saya untuk mewarisi adalah bahwa saya agak terlalu malas untuk menulis antarmuka ke semua metode dan juga saya menghubungkan kelas ke Python melalui SWIG, di mana sudah ada kode antarmuka yang baik untuk std::vector. Saya merasa lebih mudah untuk memperluas kode antarmuka ini ke kelas saya daripada menulis yang baru dari awal.

Satu-satunya masalah yang saya bisa melihat dengan pendekatan ini tidak begitu banyak dengan destructor non-virtual, melainkan beberapa metode lain, yang saya ingin overload, seperti push_back(), resize(),insert() dll warisan Swasta bisa memang menjadi pilihan yang baik.

Terima kasih!

Di sini, izinkan saya memperkenalkan 2 cara lagi untuk melakukan yang Anda inginkan. Satu adalah cara lain untuk membungkus std::vector, yang lain adalah cara untuk mewarisi tanpa memberi pengguna kesempatan untuk menghancurkan apa pun:

1. Biarkan saya menambahkan cara pembungkus lain std::vectortanpa menulis banyak fungsi pembungkus.

#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. Mewarisi dari std :: span bukannya std::vectordan menghindari masalah Dtor.

Pertanyaan ini dijamin akan menghasilkan cengkeraman mutiara yang sesak napas, tetapi pada kenyataannya tidak ada alasan yang dapat dipertahankan untuk menghindari, atau "entitas yang berlipat ganda yang tidak perlu" untuk menghindari, derivasi dari wadah Standar. Ekspresi yang paling sederhana, sesingkat mungkin adalah yang paling jelas, dan terbaik.

Anda perlu melakukan semua perawatan yang biasa untuk semua jenis turunan, tetapi tidak ada yang istimewa dengan kasing standar. Mengesampingkan fungsi anggota basis bisa rumit, tetapi itu tidak bijaksana jika dilakukan dengan basis non-virtual, jadi tidak banyak yang istimewa di sini. Jika Anda menambahkan anggota data, Anda perlu khawatir tentang mengiris jika anggota harus tetap konsisten dengan konten basis, tetapi sekali lagi itu sama untuk basis apa pun.

Tempat di mana saya menemukan berasal dari wadah standar sangat berguna adalah untuk menambahkan konstruktor tunggal yang melakukan inisialisasi yang diperlukan, tanpa kemungkinan kebingungan atau pembajakan oleh konstruktor lain. (Saya melihat Anda, konstruktor initialization_list!) Kemudian, Anda dapat dengan bebas menggunakan objek yang dihasilkan, diiris - kirimkan dengan merujuk ke sesuatu yang mengharapkan basis, pindahkan darinya ke turunan basis, apa pun yang Anda miliki. Tidak ada kasus tepi yang perlu dikhawatirkan, kecuali itu akan mengganggu Anda untuk mengikat argumen templat ke kelas turunan.

Tempat di mana teknik ini akan segera berguna dalam C ++ 20 adalah reservasi. Di mana kita mungkin telah menulis

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

kita bisa bilang

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

dan kemudian memiliki, bahkan sebagai anggota kelas,

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

(sesuai preferensi) dan tidak perlu menulis konstruktor hanya untuk memanggil cadangan () pada mereka.

(Alasan itu reserve_in , secara teknis, perlu menunggu C ++ 20 adalah bahwa Standar sebelumnya tidak memerlukan kapasitas vektor kosong untuk dipertahankan di seluruh gerakan. Itu diakui sebagai pengawasan, dan secara wajar dapat diharapkan untuk diperbaiki sebagai cacat dalam waktu untuk '20. Kita juga dapat mengharapkan perbaikan, secara efektif, mundur ke Standar sebelumnya, karena semua implementasi yang ada benar-benar melestarikan kapasitas lintas gerakan, Standar hanya tidak membutuhkannya. pemesanan senjata hampir selalu hanya merupakan pengoptimalan saja.)

Beberapa berpendapat bahwa kasus reserve_inini lebih baik dilayani oleh templat fungsi gratis:

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

Alternatif semacam itu tentu saja layak - dan bahkan, kadang-kadang, menjadi jauh lebih cepat, karena * RVO. Tetapi pilihan derivasi atau fungsi bebas harus dibuat berdasarkan kemampuannya sendiri, dan bukan dari takhayul tak berdasar (heh!) Tentang diturunkan dari komponen Standar. Dalam contoh penggunaan di atas, hanya bentuk kedua yang akan berfungsi dengan fungsi bebas; walaupun di luar konteks kelas dapat ditulis sedikit lebih ringkas:

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