C++ - przekazywanie odniesień do std:: shared ptr lub boost:: shared ptr

Stwierdziłem, że nie zgadzam się z najwyżej głosowaną odpowiedzią, więc poszedłem szukać eksperckich opinonów i oto one. Od http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2011-Scott-Andrei-and-Herb-Ask-Us-Anything

Herb Sutter: "kiedy przejdziesz shared_ptr' s, kopie są drogie "

Scott Meyers: "nie ma nic specjalnego w shared_ptr, jeśli chodzi o to, czy przekazujesz go przez wartość, czy przez odniesienie. Użyj dokładnie tej samej analizy, której używasz dla każdego inny typ zdefiniowany przez użytkownika. Ludzie wydają się mieć to postrzeganie, że shared_ptr w jakiś sposób rozwiązuje wszystkie problemy z zarządzaniem, a ponieważ jest mały, to koniecznie jest tani, aby przejść przez wartość. Trzeba go skopiować i wiąże się z tym koszt... jest to kosztowne, aby przekazać go według wartości, więc jeśli Mogę ujść na sucho z odpowiednią semantyką w moim programie, przekażę go przez odniesienie do const lub odniesienia zamiast"[3]}

Herb Sutter: "zawsze podawaj je przez odniesienie do const i bardzo czasami może dlatego, że wiesz, co nazwałeś może zmodyfikować rzecz, z której masz odniesienie, może wtedy możesz przekazać wartość... jeśli skopiujesz je jako parametry, o mój Boże, prawie nigdy nie musisz podbijać tej liczby referencji, ponieważ i tak jest utrzymywana przy życiu, i powinieneś przekazywać ją przez referencję, więc proszę zrób to" {]}

Update: Herb rozszerzył na ten temat tutaj: http://herbsutter.com/2013/06/05/gotw-91-solution-smart-pointer-parameters / , chociaż Morał z historia jest taka, że nie powinieneś w ogóle przekazywać shared_ptr", chyba że chcesz używać lub manipulować inteligentnym wskaźnikiem, takim jak udostępnianie lub przenoszenie własności."

Odradzałbym tę praktykę, chyba że ty i inni programiści, z którymi pracujesz naprawdę, Naprawdę wiecie, co robicie.

Po pierwsze, nie masz pojęcia jak może ewoluować interfejs do twojej klasy i chcesz uniemożliwić innym programistom Robienie złych rzeczy. Podanie shared_ptr przez odniesienie nie jest czymś, czego programista powinien się spodziewać, ponieważ nie jest idiomatyczne, a to sprawia, że łatwo go używać nieprawidłowo. Program: Utwórz interfejs aby użyć nieprawidłowo. Przechodzenie przez odniesienie po prostu zaprosi problemy później.

Po drugie, nie Optymalizuj, dopóki nie wiesz, że ta konkretna klasa będzie problemem. Najpierw profil, a potem, jeśli twój program naprawdę potrzebuje impulsu podanego przez odniesienie, to może. W przeciwnym razie nie przejmuj się drobnymi rzeczami (tj. dodatkowymi N instrukcjami, których potrzeba, aby przekazać wartość) zamiast martwić się o projekt, struktury danych, algorytmy i długoterminową konserwację.

Tak, biorąc odniesienia jest w porządku tam. Nie zamierzasz nadać metodzie współwłasności; ona chce tylko z nią pracować. Możesz też wziąć referencję do pierwszej sprawy, skoro i tak ją skopiujesz. Ale w pierwszym przypadku, to bierze własność. Jest taka sztuczka, aby skopiować ją tylko raz:

void ClassA::take_copy_of_sp(boost::shared_ptr<foo> sp) {
    m_sp_member.swap(sp);
}

Należy również skopiować, gdy zwracasz go (tzn. nie zwracasz referencji). Ponieważ twoja klasa nie wie, co klient z nim robi (może przechowywać wskaźnik do niego i wtedy wydarzy się wielki wybuch). Jeśli później się okaże, że to wąskie gardło (Pierwszy profil!), wtedy nadal możesz zwrócić referencję.

Edit: oczywiście, jak podkreślają inni, jest to prawdą tylko wtedy, gdy znasz swój kod i wiesz, że nie zresetujesz przekazanego wskaźnika współdzielonego w jakiś sposób. Jeśli masz wątpliwości, po prostu podaj wartość.

Sensowne jest przechodzenie shared_ptr przez const&. Nie spowoduje to problemów (z wyjątkiem mało prawdopodobnego przypadku, gdy odwołana shared_ptr zostanie usunięta podczas wywołania funkcji, jak szczegółowo opisał Earwicker) i prawdopodobnie będzie szybsza, jeśli przekażesz wiele z nich. Zapamiętaj; domyślną wartością boost::shared_ptr jest thread safe, więc kopiowanie zawiera przyrost thread safe.

Spróbuj użyć const&, a nie tylko &, ponieważ obiekty tymczasowe nie mogą być przekazywane przez referencję non-const. (Chociaż język rozszerzenie w MSVC pozwala na to i tak)

W drugim przypadku robienie tego jest prostsze:

Class::only_work_with_sp(foo &sp)
{    
    ...  
    sp.do_something();  
    ...  
}

Możesz to nazwać

only_work_with_sp(*sp);

Uniknąłbym" zwykłego " odniesienia, chyba że funkcja explicitely może zmodyfikować wskaźnik.

A const & może być sensowną mikro-optymalizacją podczas wywoływania małych funkcji - np. w celu umożliwienia dalszych optymalizacji, np. w celu usunięcia pewnych warunków. Ponadto inkrement/dekrement - ponieważ jest bezpieczny dla wątku-jest punktem synchronizacji. Nie spodziewałbym się jednak, że będzie to miało duże znaczenie w większości scenariuszy.

Ogólnie rzecz biorąc, powinieneś używać prostszego stylu, chyba że masz powód nie chcę. Następnie użyj const & konsekwentnie lub dodaj komentarz, dlaczego, jeśli używasz go tylko w kilku miejscach.

Zalecałbym przekazywanie współdzielonego wskaźnika przez const reference - semantykę, że funkcja przekazywana ze wskaźnikiem nie jest właścicielem wskaźnika, co jest czystym idiomem dla programistów.

Jedyną pułapką jest to, że w wielu programach wątkowych obiekt wskazywany przez współdzielony wskaźnik zostaje zniszczony w innym wątku. Można więc śmiało powiedzieć, że używanie const reference współdzielonego wskaźnika jest bezpieczne w programie jednowątkowym.

Przekazywanie współdzielonego wskaźnika przez referencję non-const jest czasami niebezpieczne-powodem są funkcje swap i reset, które funkcja może wywołać wewnątrz, aby zniszczyć obiekt, który jest nadal uważany za ważny po powrocie funkcji.

Nie chodzi chyba o przedwczesną optymalizację - chodzi o unikanie niepotrzebnego marnowania cykli procesora, gdy wiesz, co chcesz zrobić, a idiom kodowania został mocno przyjęty przez twoich kolegów programistów.

Tylko moje 2 grosze: -)

Wydaje się, że wszystkie plusy i minusy tutaj można uogólnić na dowolny typ przekazany przez odniesienie, a nie tylko shared_ptr. Moim zdaniem powinieneś znać semantykę przechodzenia przez odniesienie, odniesienie const i wartość i używać go poprawnie. Ale nie ma absolutnie nic z natury złego w przekazywaniu shared_ptr przez odniesienie, chyba że uważasz, że wszystkie odniesienia są złe...

Aby wrócić do przykładu:

Class::only_work_with_sp( foo &sp ) //Again, no copy here  
{    
    ...  
    sp.do_something();  
    ...  
}

Skąd wiesz, że sp.do_something() nie wybuchnie z powodu zwisający wskaźnik?

Prawda jest taka, że shared_ptr lub nie, const lub nie, to może się zdarzyć, jeśli masz wadę projektu, jak bezpośrednie lub pośrednie dzielenie własności {[2] } między wątkami, pominięcie obiektu, który ma delete this, masz okrągłą własność lub inne błędy własności.

Jedna rzecz, o której jeszcze nie wspomniałem, to to, że kiedy przekazujesz współdzielone wskaźniki przez odniesienie, tracisz domyślną konwersję, którą otrzymujesz, jeśli chcesz przekazać pochodną dzielony wskaźnik klasy przez odniesienie do współdzielonego wskaźnika klasy bazowej.

Na przykład, ten kod spowoduje błąd, ale będzie działał, jeśli zmienisz test() tak, aby współdzielony wskaźnik nie był przekazywany przez odniesienie.

#include <boost/shared_ptr.hpp>

class Base { };
class Derived: public Base { };

// ONLY instances of Base can be passed by reference.  If you have a shared_ptr
// to a derived type, you have to cast it manually.  If you remove the reference
// and pass the shared_ptr by value, then the cast is implicit so you don't have
// to worry about it.
void test(boost::shared_ptr<Base>& b)
{
    return;
}

int main(void)
{
    boost::shared_ptr<Derived> d(new Derived);
    test(d);

    // If you want the above call to work with references, you will have to manually cast
    // pointers like this, EVERY time you call the function.  Since you are creating a new
    // shared pointer, you lose the benefit of passing by reference.
    boost::shared_ptr<Base> b = boost::dynamic_pointer_cast<Base>(d);
    test(b);

    return 0;
}

Zakładam, że jesteś zaznajomiony z przedwczesną optymalizacją i prosisz o to albo w celach akademickich, albo dlatego, że wyizolowałeś jakiś wcześniej istniejący kod, który jest niewystarczająco wydajny.

Przechodzenie przez odniesienie jest w porządku

Przechodzenie przez referencję const jest lepsze i zwykle może być używane, ponieważ nie wymusza zgodności na wskazywanym obiekcie.

Jesteś Nie ryzykujesz utratę WSKAŹNIKA z powodu użycia referencji. To odniesienie jest dowodem że masz kopię inteligentnego wskaźnika wcześniej w stosie i tylko jeden wątek posiada stos wywołań, tak że wcześniej istniejąca Kopia nie zniknie.

Używanie referencji jest często bardziej efektywne z wymienionych powodów, ale nie gwarantowane. Pamiętaj, że dereferencja obiektu również może wymagać pracy. Twój idealny scenariusz użycia odniesienia byłby taki, gdyby twój styl kodowania obejmował wiele małych funkcji, w których wskaźnik byłby przekazywany z funkcji do funkcji funkcja przed użyciem.

Powinieneś zawsze unikać przechowywania inteligentnego wskaźnika jako punktu odniesienia. Twój przykład Class::take_copy_of_sp(&sp) pokazuje poprawne użycie w tym celu.

Zakładając, że nie zajmujemy się poprawnością const (lub bardziej, masz na myśli umożliwienie funkcjom modyfikowania lub współdzielenia własności przekazywanych danych), przekazywanie wartości boost:: shared_ptr przez wartość jest bezpieczniejsze niż przekazywanie jej przez odniesienie, ponieważ pozwalamy oryginalnemu boost::shared_ptr kontrolować swój własny czas życia. Rozważmy wyniki poniższego kodu...

void FooTakesReference( boost::shared_ptr< int > & ptr )
{
    ptr.reset(); // We reset, and so does sharedA, memory is deleted.
}

void FooTakesValue( boost::shared_ptr< int > ptr )
{
    ptr.reset(); // Our temporary is reset, however sharedB hasn't.
}

void main()
{
    boost::shared_ptr< int > sharedA( new int( 13 ) );
    boost::shared_ptr< int > sharedB( new int( 14 ) );

    FooTakesReference( sharedA );

    FooTakesValue( sharedB );
}

Z powyższego przykładu widzimy, że przekazanie sharedA przez referencję Pozwala FooTakesReference na zresetuj oryginalny wskaźnik, co zmniejsza jego liczbę użycia do 0, niszcząc jego dane. FooTakesValue , jednakże, nie może zresetować oryginalnego wskaźnika, gwarantując, że dane sharedB są nadal użyteczne. Kiedy pojawia się inny deweloper i próbuje wykorzystać kruchą egzystencję sharedy, następuje chaos. Jednak szczęśliwy programistasharedB wraca do domu wcześnie, ponieważ wszystko jest w jego świecie.

Bezpieczeństwo kodu, w tym przypadku, znacznie przewyższa prędkość poprawa kopiowanie tworzy. Jednocześnie boost:: shared_ptr ma na celu poprawę bezpieczeństwa kodu. Znacznie łatwiej będzie przejść od kopii do referencji, jeśli coś wymaga tego rodzaju optymalizacji niszowej.

Sandy napisał (a): wydaje się, że wszystkie plusy i minusy tutaj można faktycznie uogólnić na dowolny typ przekazywany przez odniesienie, a nie tylko shared_ptr."

Prawda do pewnego stopnia, ale celem użycia shared_ptr jest wyeliminowanie obaw dotyczących życia obiektów i umożliwienie kompilatorowi obsługi tego za Ciebie. Jeśli chcesz przekazać współdzielony wskaźnik przez odniesienie i zezwolić klientom metod non-const, które mogą uwolnić dane obiektu, użyj współdzielonego wskaźnika to prawie bezcelowe.

Napisałem "prawie" w poprzednim zdaniu, ponieważ wydajność może być problemem, i to "może" być uzasadnione w rzadkich przypadkach, ale chciałbym również uniknąć tego scenariusza i szukać wszystkich możliwych innych rozwiązań optymalizacyjnych, takich jak poważnie spojrzeć na dodanie kolejnego poziomu indrection, leniwa ocena, itp..

Kod, który istnieje po jego autorze, a nawet po jego pamięci autora, który wymaga ukrytych założeń dotyczących zachowania, w szczególności zachowanie o życiu obiektu wymaga jasnej, zwięzłej, czytelnej dokumentacji, a wtedy wielu klientów i tak jej nie przeczyta! Prostota prawie zawsze przewyższa wydajność, a prawie zawsze są inne sposoby na efektywność. Jeśli naprawdę potrzebujesz przekazać wartości przez odniesienie, aby uniknąć głębokiego kopiowania przez konstruktory kopiujące obiektów z liczeniem odniesień( i operatora equals), to być może powinieneś rozważyć sposoby, aby głęboko skopiowane dane były wskaźnikami z liczeniem odniesień, które można skopiować szybko. (Oczywiście, to tylko jeden scenariusz projektowy, który może nie mieć zastosowania do twojej sytuacji).

Kiedyś pracowałem w projekcie, że zasada była bardzo silna o przekazywaniu inteligentnych wskaźników przez wartość. Kiedy zostałem poproszony o wykonanie analizy wydajności-odkryłem, że dla zwiększania i zmniejszania liczników referencyjnych inteligentnych wskaźników aplikacja spędza między 4-6% czasu wykorzystywanego procesora.

Jeśli chcesz przekazać inteligentne wskaźniki według wartości, aby uniknąć problemów w dziwnych przypadkach opisanych przez Daniela Earwickera, upewnij się, że rozumiesz cenę, którą chcesz płacę za to.

Jeśli zdecydujesz się użyć referencji, głównym powodem użycia referencji const jest umożliwienie niejawnego upcastingu, gdy musisz przekazać współdzielony wskaźnik do obiektu z klasy, która dziedziczy klasę używaną w interfejsie.

Oprócz tego, co powiedział litb, chciałbym zaznaczyć, że prawdopodobnie przejdzie przez const reference w drugim przykładzie, w ten sposób masz pewność, że nie przypadkowo go zmodyfikować.

struct A {
  shared_ptr<Message> msg;
  shared_ptr<Message> * ptr_msg;
}

1. Pass by value:

   void set(shared_ptr<Message> msg) {
     this->msg = msg; /// create a new shared_ptr, reference count will be added;
   } /// out of method, new created shared_ptr will be deleted, of course, reference count also be reduced;
   

2. Pass by reference:

   void set(shared_ptr<Message>& msg) {
    this->msg = msg; /// reference count will be added, because reference is just an alias.
    }
   

3. Podaj wskaźnik:

   void set(shared_ptr<Message>* msg) {
     this->ptr_msg = msg; /// reference count will not be added;
   }
   

Każdy element kodu musi mieć jakiś sens. Jeśli przekazujesz współdzielony wskaźnik przez wartość wszędzie w aplikacji, oznacza to " nie jestem pewien, co się dzieje gdzie indziej, dlatego preferuję surowe Bezpieczeństwo ". To nie jest to, co nazywam dobrym znakiem zaufania dla innych programistów, którzy mogliby skonsultować kod.

W każdym razie, nawet jeśli funkcja otrzymuje referencję const i jesteś "niepewny", nadal możesz utworzyć kopię współdzielonego wskaźnika na czele funkcji, aby dodać silny odniesienie do wskaźnika. Może to być również postrzegane jako wskazówka o projekcie ("wskaźnik można zmodyfikować gdzie indziej").

Więc tak, IMO, domyślnie powinno być " pass by const reference ".