Czy powinniśmy przekazać współdzielony PST według referencji czy wartości?

Oto herb Sutter ' s take

Wytyczna: nie przekazuj inteligentnego wskaźnika jako parametru funkcji, chyba że chcesz używać lub manipulować samym inteligentnym wskaźnikiem, na przykład udział lub przeniesienie własności.

Wytyczna: wyrażenie, że funkcja będzie przechowywać i dzielić własność obiekt heap za pomocą parametru shared_ptr.

Wytyczna: użyj a non - const shared_ptr & parametr tylko do modyfikacji shared_ptr. Użyj a const shared_ptr & as a parametr tylko wtedy, gdy nie jesteś pewien, czy lub nie będziesz wziąć kopię i współwłasność; w przeciwnym razie użyj widżetu* zamiast tego (lub jeśli nie nullable, widżet&).

Osobiście użyłbym const referencji. Nie ma potrzeby zwiększania liczby referencji tylko po to, aby ponownie ją zmniejszyć w celu wywołania funkcji.

/ Align = "left" / Jeśli chcesz go przechowywać, powiedzmy w jakimś pojemniku, ref. licznik będzie automatycznie zwiększany przez operację kopiowania.

Uruchomiłem poniższy kod, raz z foo Biorąc shared_ptr przez const& i ponownie z foo Biorąc shared_ptr przez wartość.

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

Korzystanie z VS2015, X86 release build, na moim procesorze intel Core 2 quad (2.4 GHz)

const shared_ptr&     - 10ms  
shared_ptr            - 281ms 

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

Od C++11 powinieneś wziąć go przez wartość nad const& częściej niż mogłoby się wydawać.

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

Jeśli chcesz skopiować gdzieś , bardziej sensowne jest zabranie go przez copy, a std::przenieś go wewnętrznie, zamiast wziąć go przez const&, a następnie skopiować. Dzieje się tak dlatego, że pozwalasz rozmówcy na opcję w włącz std:: przenieś shared_ptr podczas wywoływania funkcji, zachowując w ten sposób zestaw operacji przyrostowych i przyrostowych. Albo i nie. Oznacza to, że wywołujący funkcję może zdecydować, czy potrzebuje std::shared_ptr po wywołaniu funkcji i w zależności od tego, czy się przesunie, czy nie. Nie jest to osiągalne, jeśli przejdziesz przez const&, a zatem najlepiej jest wziąć go według wartości.

Oczywiście, jeśli wywołujący potrzebuje swojego shared_ptr na dłużej (więc nie może std:: move it) i nie chcesz tworzyć zwykłej kopii w funkcji (powiedzmy, że chcesz słaby wskaźnik lub tylko czasami chcesz go skopiować, w zależności od jakiegoś warunku), wtedy const& może być nadal preferowany.

Na przykład, powinieneś zrobić

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

Over

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

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

Nie znając kosztu czasu operacji kopiowania shared_copy gdzie jest inkrement i dekrement atomowy, cierpiałem na znacznie większy problem z użyciem procesora. Nigdy nie spodziewałem się, że przyrost atomowy i spadek może wymagać tak dużych kosztów.

Po moim wyniku testu, int32 przyrost atomowy i zmniejszanie trwa 2 lub 40 razy niż przyrost i zmniejszanie niematomiczne. Mam go na 3GHz Core i7 z Windows 8.1. Pierwszy wynik wychodzi, gdy nie występuje spór, drugi, gdy duża możliwość występuje spór. Mam na uwadze, że operacje atomowe są w końcu blokadą sprzętową. Zamek to zamek. Złe do wydajności, gdy występuje niezgodność.

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

Shared_ptr nie jest wystarczająco duży, ani jego konstruktor\destructor nie wykonuje wystarczająco dużo pracy, aby nie było wystarczająco dużo narzutu z kopii, aby dbać o wydajność pass by reference vs pass by copy.