Haruskah kita meneruskan shared_ptr dengan referensi atau berdasarkan nilai?

Saat fungsi mengambil shared_ptr(dari boost atau C ++ 11 STL), apakah Anda mengopernya:

• dengan referensi const: void foo(const shared_ptr<T>& p)

• atau berdasarkan nilai void foo(shared_ptr<T> p):?

Saya lebih suka metode pertama karena saya curiga akan lebih cepat. Tetapi apakah ini benar-benar layak atau adakah masalah tambahan?

Bisakah Anda memberikan alasan untuk pilihan Anda atau jika kasusnya, mengapa Anda pikir itu tidak masalah.

Pertanyaan ini telah didiskusikan dan dijawab oleh Scott, Andrei dan Herb selama sesi Ask Us Anything di C ++ and Beyond 2011 . Tonton mulai 4:34 tentang shared_ptrkinerja dan kebenaran .

Singkatnya, tidak ada alasan untuk memberikan nilai, kecuali tujuannya adalah untuk berbagi kepemilikan atas suatu objek (mis. Antara struktur data yang berbeda, atau antara utas yang berbeda).

Kecuali Anda dapat menggerakkan-mengoptimalkannya seperti yang dijelaskan oleh Scott Meyers dalam video pembicaraan yang ditautkan di atas, tetapi itu terkait dengan versi aktual C ++ yang dapat Anda gunakan.

Pembaruan besar untuk diskusi ini telah terjadi selama Panel Interaktif konferensi GoingNative 2012 : Tanyakan Apa Pun ! yang layak ditonton, terutama dari 22:50 .

Ini ramuan Herb Sutter

Pedoman: Jangan melewatkan pointer pintar sebagai parameter fungsi kecuali jika Anda ingin menggunakan atau memanipulasi pointer pintar itu sendiri, seperti untuk berbagi atau mentransfer kepemilikan.

Guideline: Mengungkapkan bahwa suatu fungsi akan menyimpan dan berbagi kepemilikan dari objek heap menggunakan parameter shared_ptr dengan-nilai.

Pedoman: Gunakan non-const shared_ptr & parameter hanya untuk memodifikasi shared_ptr. Gunakan const shared_ptr & sebagai parameter hanya jika Anda tidak yakin apakah Anda akan mengambil salinan dan berbagi kepemilikan; jika tidak gunakan widget * sebagai gantinya (atau jika tidak dapat dibatalkan, widget &).

Secara pribadi saya akan menggunakan constreferensi. Tidak perlu menambah jumlah referensi hanya untuk mengurangi lagi demi pemanggilan fungsi.

Lulus dengan constreferensi, lebih cepat. Jika Anda perlu menyimpannya, katakan dalam beberapa wadah, ref. hitungan akan bertambah secara ajaib oleh operasi penyalinan.

Aku berlari kode di bawah ini, sekali dengan foomengambil shared_ptroleh const&dan lagi dengan foomengambil shared_ptrberdasarkan nilai.

void foo(const std::shared_ptr<int>& p)
{
    static int x = 0;
    *p = ++x;
}

int main()
{
    auto p = std::make_shared<int>();
    auto start = clock();
    for (int i = 0; i < 10000000; ++i)
    {
        foo(p);
    }    
    std::cout << "Took " << clock() - start << " ms" << std::endl;
}

Menggunakan VS2015, build rilis x86, pada prosesor intel core 2 quad (2.4GHz) saya

const shared_ptr&     - 10ms  
shared_ptr            - 281ms 

Salinan menurut versi nilai adalah urutan besarnya lebih lambat.
Jika Anda memanggil fungsi secara sinkron dari utas saat ini, lebih suka const&versinya.

Karena C ++ 11 Anda harus mengambilnya dengan nilai lebih dari const & lebih sering daripada yang Anda pikirkan.

Jika Anda menggunakan std :: shared_ptr (daripada tipe T yang mendasarinya), maka Anda melakukannya karena Anda ingin melakukan sesuatu dengannya.

Jika Anda ingin menyalinnya suatu tempat, lebih masuk akal untuk mengambilnya dengan menyalin, dan std :: memindahkannya secara internal, daripada mengambilnya dengan const & dan kemudian menyalinnya. Ini karena Anda membiarkan opsi penelepon pada gilirannya std :: memindahkan shared_ptr saat memanggil fungsi Anda, sehingga menghemat sendiri satu set operasi kenaikan dan penurunan. Atau tidak. Artinya, pemanggil fungsi dapat memutuskan apakah dia memerlukan std :: shared_ptr di sekitar setelah memanggil fungsi, dan tergantung pada apakah atau tidak bergerak atau tidak. Ini tidak dapat dicapai jika Anda melewati const &, dan karena itu lebih disukai untuk mengambilnya dengan nilai.

Tentu saja, jika pemanggil keduanya membutuhkan shared_ptr-nya lebih lama (sehingga tidak dapat std :: memindahkannya) dan Anda tidak ingin membuat salinan polos dalam fungsi (misalkan Anda ingin penunjuk yang lemah, atau Anda hanya kadang-kadang ingin untuk menyalinnya, tergantung pada beberapa kondisi), maka konst & mungkin masih lebih disukai.

Misalnya, Anda harus melakukannya

void enqueue(std::shared<T> t) m_internal_queue.enqueue(std::move(t));

lebih

void enqueue(std::shared<T> const& t) m_internal_queue.enqueue(t);

Karena dalam hal ini Anda selalu membuat salinan secara internal

Tidak tahu biaya waktu operasi copy shared_copy di mana peningkatan dan penurunan atom, saya menderita masalah penggunaan CPU yang jauh lebih tinggi. Saya tidak pernah menyangka peningkatan dan penurunan atom mungkin memakan banyak biaya.

Setelah hasil pengujian saya, kenaikan dan penurunan atom int32 membutuhkan 2 atau 40 kali lipat daripada kenaikan dan penurunan non-atom. Saya mendapatkannya di 3GHz Core i7 dengan Windows 8.1. Hasil pertama muncul ketika tidak ada pertengkaran yang terjadi, yang terakhir ketika kemungkinan pertengkaran tinggi terjadi. Saya ingat bahwa operasi atom pada kunci berbasis perangkat keras yang terakhir. Kunci adalah kunci. Buruk terhadap kinerja saat pertikaian terjadi.

Mengalami ini, saya selalu menggunakan byref (const shared_ptr &) daripada byval (shared_ptr).

Ada posting blog baru-baru ini: https://medium.com/@vgasparyan1995/pass-by-value-vs-pass-by-reference-to-const-c-f8944171e3ce

Jadi jawabannya adalah: Jangan (hampir) tidak pernah lewat const shared_ptr<T>&.
Cukup lulus kelas yang mendasarinya saja.

Pada dasarnya satu-satunya jenis parameter yang masuk akal adalah:

• shared_ptr<T> - Ubah dan ambil kepemilikan
• shared_ptr<const T> - Jangan modifikasi, ambil kepemilikan
• T& - Ubah, tidak ada kepemilikan
• const T& - Jangan modifikasi, tidak ada kepemilikan
• T - Jangan modifikasi, tanpa kepemilikan, Murah untuk menyalin

Seperti @accel tunjukkan dalam https://stackoverflow.com/a/26197326/1930508 saran dari Herb Sutter adalah:

Gunakan const shared_ptr & sebagai parameter hanya jika Anda tidak yakin apakah Anda akan mengambil salinan dan berbagi kepemilikan

Tetapi dalam berapa kasus Anda tidak yakin? Jadi ini adalah situasi yang jarang terjadi

Sudah diketahui masalah bahwa meneruskan shared_ptr menurut nilai memiliki biaya dan harus dihindari jika mungkin.

Biaya melewati dengan shared_ptr

Sebagian besar waktu lewat shared_ptr dengan referensi, dan bahkan lebih baik dengan referensi const, akan dilakukan.

Pedoman inti cpp memiliki aturan khusus untuk meneruskan shared_ptr

R.34: Ambil parameter shared_ptr untuk menyatakan bahwa suatu fungsi adalah pemilik bagian

void share(shared_ptr<widget>);            // share -- "will" retain refcount

Contoh kapan lewat shared_ptr menurut nilai sangat diperlukan adalah ketika pemanggil meneruskan objek yang dibagi ke callee asinkron - yaitu pemanggil keluar dari ruang lingkup sebelum callee menyelesaikan tugasnya. Callee harus "memperpanjang" masa pakai objek yang dibagikan dengan mengambil nilai share_ptr. Dalam hal ini, meneruskan referensi ke shared_ptr tidak akan berhasil.

Hal yang sama berlaku untuk melewatkan objek bersama ke utas kerja.

shared_ptr tidak cukup besar, konstruktor \ destruktornya juga tidak cukup bekerja agar ada overhead yang cukup dari salinan untuk peduli dengan referensi demi referensi vs demi kinerja copy.