Czy powinniśmy przekazać shared_ptr przez referencję czy wartość?

Gdy funkcja przyjmuje wartość shared_ptr (z boost lub C ++ 11 STL), przekazujesz ją:

• według stałej referencji: void foo(const shared_ptr<T>& p)

• lub według wartości void foo(shared_ptr<T> p):?

Wolałbym pierwszą metodę, ponieważ podejrzewam, że byłaby szybsza. Ale czy to naprawdę jest tego warte, czy są jakieś dodatkowe problemy?

Czy możesz podać powody swojego wyboru lub, jeśli tak, dlaczego uważasz, że to nie ma znaczenia.

To pytanie zostało omówione i udzielone przez Scott, Andrei i Herb podczas sesji Ask Us Anything w C ++ i Beyond 2011 . Obejrzyj od 4:34 na temat shared_ptrwydajności i poprawności .

Krótko mówiąc, nie ma powodu, by przekazywać wartość, chyba że celem jest współwłasność własności obiektu (np. Między różnymi strukturami danych lub między różnymi wątkami).

O ile nie możesz go zoptymalizować w ruchu, jak wyjaśnił Scott Meyers w powyższym filmie dyskusyjnym, ale jest to związane z faktyczną wersją C ++, której możesz użyć.

Główna aktualizacja tej dyskusji nastąpiła podczas interaktywnego panelu konferencji GoingNative 2012 : Zapytaj nas o wszystko! co warto obejrzeć, zwłaszcza od 22:50 .

Oto ujęcie Herb Suttera

Wskazówka: Nie przekazuj inteligentnego wskaźnika jako parametru funkcji, chyba że chcesz używać lub manipulować samym inteligentnym wskaźnikiem, na przykład w celu współdzielenia lub przeniesienia własności.

Wytyczna: Wyraź, że funkcja będzie przechowywać i współdzielić własność obiektu sterty za pomocą parametru wartości_podzielonej by-value.

Wskazówka: Użyj nie-const parametru shared_ptr i tylko do zmodyfikowania parametru shared_ptr. Użyj stałej shared_ptr & jako parametru tylko wtedy, gdy nie masz pewności, czy zrobisz kopię i udostępnisz własność; w przeciwnym razie użyj widget * (lub jeśli nie ma wartości null, widget &).

Osobiście użyłbym constreferencji. Nie ma potrzeby zwiększania liczby referencyjnej tylko po to, aby ją ponownie zmniejszyć ze względu na wywołanie funkcji.

Przekaż przez constodniesienie, jest szybszy. Jeśli chcesz go przechowywać, powiedzmy w jakimś pojemniku, ref. liczba zostanie automatycznie zwiększona przez operację kopiowania.

Uruchomiłem poniższy kod, raz z fooprzyjmowaniem wartości „ shared_ptrby by” const&i „raz po raz” z fooprzyjmowaniem shared_ptrwartości według.

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

Używając wersji VS2015, x86, na moim czterordzeniowym procesorze Intel Core 2 (2,4 GHz)

const shared_ptr&     - 10ms  
shared_ptr            - 281ms 

Wersja kopiowania według wartości była wolniejsza o rząd wielkości.
Jeśli wywołujesz funkcję synchronicznie z bieżącego wątku, wybierz const&wersję.

Od C ++ 11 powinieneś brać to pod względem wartości ponad const i częściej niż myślisz.

Jeśli bierzesz std :: shared_ptr (zamiast bazowego typu T), robisz to, ponieważ chcesz coś z tym zrobić.

Jeśli chcesz go gdzieś skopiować , sensowniej jest zabrać go za pomocą kopiowania i przenieść std :: wewnętrznie, zamiast zabierać to przez const &, a następnie kopiowanie. Jest tak, ponieważ pozwalasz wywołującemu opcję z kolei std :: move shared_ptr podczas wywoływania twojej funkcji, oszczędzając w ten sposób sobie zestaw operacji zwiększania i zmniejszania. Albo nie. Oznacza to, że wywołujący funkcję może zdecydować, czy potrzebuje std :: shared_ptr po wywołaniu funkcji, w zależności od tego, czy się poruszy, czy nie. Nie jest to możliwe, jeśli przejdziesz przez const &, a zatem najlepiej jest przyjąć wartość.

Oczywiście, jeśli osoba wywołująca potrzebuje dłużej swojej shared_ptr (więc nie może std :: move it) i nie chcesz tworzyć zwykłej kopii w funkcji (powiedz, że chcesz słaby wskaźnik, lub tylko czasami chcesz aby go skopiować, w zależności od niektórych warunków), wtedy const i może być nadal preferowane.

Na przykład powinieneś to zrobić

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

nad

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

Ponieważ w takim przypadku zawsze tworzysz kopię wewnętrznie

Nie znając kosztu czasu operacji kopiowania shared_copy, w której występuje przyrost i spadek atomowy, cierpiałem z powodu znacznie większego problemu z użyciem procesora. Nigdy nie spodziewałem się, że przyrost atomowy i dekrementacja mogą kosztować tyle.

Po moim teście, przyrost i spadek atomowy int32 zajmuje 2 lub 40 razy niż wzrost i spadek nieatomowy. Mam go na Core i7 3GHz z Windows 8.1. Pierwszy wynik pojawia się, gdy nie dochodzi do rywalizacji, drugi, gdy występuje duża możliwość rywalizacji. Pamiętam, że operacje atomowe są w końcu blokadą sprzętową. Zamek jest zamkiem. Zła wydajność, gdy występuje rywalizacja.

Doświadczając tego, zawsze używam byref (const shared_ptr &) niż byval (shared_ptr).

Był ostatni post na blogu: https://medium.com/@vgasparyan1995/pass-by-value-vs-pass-by-reference-to-const-c-f8944171e3ce

Odpowiedź na to brzmi: nigdy (prawie) nigdy nie omijaj const shared_ptr<T>&.
Zamiast tego po prostu przekaż klasę bazową.

Zasadniczo jedynymi rozsądnymi typami parametrów są:

• shared_ptr<T> - Zmień i przejmij własność
• shared_ptr<const T> - Nie modyfikuj, przejmuj na własność
• T& - Zmień, bez prawa własności
• const T& - Nie modyfikuj, brak prawa własności
• T - Nie modyfikuj, nie posiadaj, tanie do skopiowania

Jak zauważył @accel w https://stackoverflow.com/a/26197326/1930508 rada Herb Sutter jest następująca:

Użyj stałej shared_ptr & jako parametru tylko wtedy, gdy nie masz pewności, czy zrobisz kopię i udostępnisz własność

Ale w ilu przypadkach nie jesteś pewien? To rzadka sytuacja

Znany jest problem polegający na tym, że przekazywanie wartości parametru shared_ptr wiąże się z pewnymi kosztami i należy go w miarę możliwości unikać.

Koszt przejścia przez shared_ptr

Przeważnie wystarczyłoby dzielenie share_ptr przez referencję, a jeszcze lepiej przez const referen.

Podstawowa wytyczna cpp ma określoną zasadę przekazywania komendy shared_ptr

R.34: Weź parametr shared_ptr, aby wyrazić, że funkcja jest właścicielem części

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

Przykładem, gdy przekazanie parametru shared_ptr przez wartość jest naprawdę konieczne, jest to, gdy obiekt wywołujący przekazuje obiekt współdzielony do asynchronicznego odbiorcy - tzn. Dzwoniący wykracza poza zakres, zanim odbiorca zakończy swoje zadanie. Odbiorca musi „przedłużyć” żywotność współdzielonego obiektu, biorąc wartość share_ptr według wartości. W takim przypadku przekazanie odwołania do shared_ptr nie zadziała.

To samo dotyczy przekazywania współdzielonego obiektu do wątku roboczego.

shared_ptr nie jest wystarczająco duży, ani jego konstruktor \ destruktor nie wykonuje wystarczającej pracy, aby z kopii było wystarczające obciążenie, aby dbać o przekazywanie przez odniesienie w porównaniu do wydajności kopiowania przez kopię.