Przekazywanie wspólnych wskaźników jako argumentów

Jeśli zadeklaruję obiekt zawinięty we współdzielony wskaźnik:

std::shared_ptr<myClass> myClassObject(new myClass());

następnie chciałem przekazać to jako argument do metody:

DoSomething(myClassObject);

//the called method
void DoSomething(std::shared_ptr<myClass> arg1)
{
   arg1->someField = 4;
}

Czy powyższe po prostu zwiększa liczbę referencji shared_pt i wszystko jest w porządku? A może pozostawia zwisający wskaźnik?

Nadal masz to zrobić ?:

DoSomething(myClassObject.Get());

void DoSomething(std::shared_ptr<myClass>* arg1)
{
   (*arg1)->someField = 4;
}

Myślę, że drugi sposób może być bardziej wydajny, ponieważ musi skopiować tylko 1 adres (w przeciwieństwie do całego inteligentnego wskaźnika), ale pierwszy sposób wydaje się bardziej czytelny i nie przewiduję przesuwania granic wydajności. Chcę się tylko upewnić, że nie ma w tym nic niebezpiecznego.

Dziękuję Ci.

Chcę przekazać wspólny wskaźnik do funkcji. Czy możesz mi z tym pomóc?

Jasne, mogę ci w tym pomóc. Zakładam, że rozumiesz semantykę własności w C ++. Czy to prawda?

Tak, ten temat jest mi dość wygodny.

Dobry.

Ok, przychodzą mi do głowy tylko dwa powody, dla których warto się shared_ptrkłócić:

1. Funkcja chce współdzielić własność obiektu;
2. Funkcja wykonuje pewną operację, która działa specjalnie na shared_ptrs.

Który Cię interesuje?

Szukam ogólnej odpowiedzi, więc właściwie jestem zainteresowany obydwoma. Jestem jednak ciekawy, co masz na myśli w przypadku nr 2.

Przykładami takich funkcji są std::static_pointer_castkomparatory niestandardowe lub predykaty. Na przykład, jeśli chcesz znaleźć wszystkie unikalne shared_ptr z wektora, potrzebujesz takiego predykatu.

Ach, kiedy funkcja faktycznie musi manipulować samym inteligentnym wskaźnikiem.

Dokładnie.

W takim przypadku uważam, że powinniśmy przejść przez odniesienie.

Tak. A jeśli to nie zmieni wskaźnika, chcesz przejść przez odwołanie do stałej. Nie ma potrzeby kopiowania, ponieważ nie musisz dzielić się własnością. To jest inny scenariusz.

Ok, rozumiem. Porozmawiajmy o innym scenariuszu.

Ten, w którym jesteś współwłasnością? Ok. W jaki sposób dzielisz się własnością shared_ptr?

Kopiując to.

Wtedy funkcja będzie musiała wykonać kopię shared_ptr, prawda?

Oczywiście. Więc przekazuję to przez odniesienie do stałej i kopiuję do zmiennej lokalnej?

Nie, to pesymizacja. Jeśli zostanie przekazany przez odniesienie, funkcja nie będzie miała innego wyboru, jak tylko wykonać kopię ręcznie. Jeśli zostanie przekazana przez wartość, kompilator wybierze najlepszy wybór między kopiowaniem a przeniesieniem i wykona go automatycznie. Więc podaj wartość.

Słuszna uwaga. Muszę częściej pamiętać ten artykuł „ Chcesz szybkości? Przekaż wartość ”.

Czekaj, co jeśli funkcja na przykład przechowuje shared_ptrzmienną składową? Czy to nie spowoduje zbędnej kopii?

Funkcja może po prostu przenieść shared_ptrargument do swojej pamięci. Przeniesienie a shared_ptrjest tanie, ponieważ nie zmienia liczby odniesień.

Ach, dobry pomysł.

Ale myślę o trzecim scenariuszu: co jeśli nie chcesz manipulować shared_ptrani dzielić się własnością?

W takim przypadku shared_ptrjest całkowicie bez znaczenia dla funkcji. Jeśli chcesz manipulować wskazanym, weź go i pozwól dzwoniącym wybrać, jakiej semantyki własności chcą.

I czy powinienem traktować wskazanego przez odniesienie czy według wartości?

Obowiązują standardowe zasady. Inteligentne wskazówki niczego nie zmieniają.

Przekaż wartość, jeśli mam zamiar kopiować, przekaż przez odniesienie, jeśli chcę uniknąć kopiowania.

Dobrze.

Hmm. Myślę, że zapomniałeś o innym scenariuszu. A jeśli chcę dzielić się własnością, ale tylko pod pewnymi warunkami?

Ach, ciekawy skrajny przypadek. Nie spodziewam się, że zdarzy się to często. Ale kiedy to się stanie, możesz albo przekazać wartość i zignorować kopię, jeśli jej nie potrzebujesz, albo przekazać przez odniesienie i utworzyć kopię, jeśli jej potrzebujesz.

Ryzykuję jedną zbędną kopię w pierwszej opcji i tracę potencjalny ruch w drugiej. Nie mogę zjeść ciasta i też go mieć?

Jeśli jesteś w sytuacji, w której to naprawdę ma znaczenie, możesz zapewnić dwa przeciążenia, jedno pobierające odwołanie do stałej lwartości, a drugie pobierające odwołanie do wartości r. Jedna kopia, druga się porusza. Szablon funkcji doskonałego przekazywania to kolejna opcja.

Myślę, że obejmuje to wszystkie możliwe scenariusze. Dziękuję Ci bardzo.

Myślę, że ludzie niepotrzebnie boją się używania surowych wskaźników jako parametrów funkcji. Jeśli funkcja nie będzie przechowywać wskaźnika lub w inny sposób wpływać na jego żywotność, surowy wskaźnik działa równie dobrze i reprezentuje najniższy wspólny mianownik. Zastanów się na przykład, jak przekazać a unique_ptrdo funkcji, która przyjmuje shared_ptrparametr a jako parametr, według wartości lub przez odwołanie do stałej?

void DoSomething(myClass * p);

DoSomething(myClass_shared_ptr.get());
DoSomething(myClass_unique_ptr.get());

Surowy wskaźnik jako parametr funkcji nie zapobiega używaniu inteligentnych wskaźników w kodzie wywołującym, gdzie jest to naprawdę ważne.

Tak, cała idea shared_ptr <> polega na tym, że wiele instancji może przechowywać ten sam surowy wskaźnik, a podstawowa pamięć zostanie zwolniona tylko wtedy, gdy ostatnia instancja shared_ptr <> zostanie zniszczona.

Unikałbym wskaźnika do shared_ptr <>, ponieważ jest to sprzeczne z celem, ponieważ teraz znowu masz do czynienia z raw_pointers.

Przekazywanie wartości w pierwszym przykładzie jest bezpieczne, ale jest lepszy idiom. Jeśli to możliwe, przekazuj przez odniesienie const - powiedziałbym, że tak, nawet w przypadku inteligentnych wskaźników. Twój drugi przykład nie jest całkiem zepsuty, ale jest bardzo !???. Głupie, nie osiągając niczego i pokonując część sensu inteligentnych wskazówek, i zostawiając cię w powolnym świecie bólu, gdy próbujesz wyłuskać i zmodyfikować rzeczy.

w funkcji DoSomething zmieniasz element członkowski danych instancji klasy, myClass więc modyfikujesz obiekt zarządzany (nieprzetworzony wskaźnik), a nie obiekt (shared_ptr). Oznacza to, że w punkcie powrotu tej funkcji wszystkie współdzielone wskaźniki do zarządzanego wskaźnika surowego zobaczą swój element członkowski danych: myClass::someFieldzmieniony na inną wartość.

w tym przypadku przekazujesz obiekt funkcji z gwarancją, że jej nie modyfikujesz (mówimy o shared_ptr, a nie o posiadanym obiekcie).

Idiomem, który to wyraża, jest: a const ref, tak jak to

void DoSomething(const std::shared_ptr<myClass>& arg)

Podobnie zapewniasz użytkownika swojej funkcji, że nie dodajesz kolejnego właściciela do listy właścicieli surowego wskaźnika. Jednak zachowałeś możliwość modyfikacji podstawowego obiektu wskazywanego przez surowy wskaźnik.

CAVEAT: Co oznacza, że ​​jeśli w jakiś sposób ktoś shared_ptr::resetwywoła przed wywołaniem Twojej funkcji, aw tym momencie jest to ostatni shared_ptr będący właścicielem raw_ptr, to twój obiekt zostanie zniszczony, a twoja funkcja będzie manipulować wiszącym wskaźnikiem na zniszczonym obiekcie. BARDZO NIEBEZPIECZNE!!!