[G.....9]

Jak powszechnie wiadomo shared_ptr to gówno. Jak pisać dobry kod bez niego? Wszędzie używać referencji? Jak wtedy chronić się przed referencjami do nieistniejących obiektów?

Co z konstrukcjami typu std::vector<std::shared_ptr<T>> ? Czym je zastąpić?

#cpp

[r00ti]

@Gerax9: czemu shared_ptr to gowno?

[MamCieNaHita]

@Gerax9: shared_ptr nie jest gównem, jest ostatecznością. grunt to uzmysłowić sobie kto jest właścicielem obiektu i czy jest polimorficzny

[Feargan]

@Gerax9:

Co z konstrukcjami typu std::vector<std::sharedptr<T>> ?

Zależy od przypadku użycia. Na przykład, jeżeli jesteś w stanie zagwarantować, że obiekty w wektorze "przeżyją" ten wektor, to co jest złego w surowych wskaźnikach? Przez właśnie taką paranoję powstają dziwactwa jak std::observer_ptr ( ͡° ͜ʖ ͡°)
I prawdopodobnie takie powinno być jedyne znaczenie surowych wskaźników we współczesnym C++ - odniesienie do obiektu, którego nie jesteśmy właścicielem.

[G.....9]

@r00ti: Bo ma zły design i jest koszmarnie wolny.

@MamCieNaHita

shared_ptr nie jest gównem, jest ostatecznością

Jest to kwestia dyskusyjna, w niektórych projektach użycie shared_pointera zostało zbanowane.

@Feargan

co jest złego w surowych wskaźnikach?

Problem ten sam co przy referencjach, nie da się sprawdzić, czy wskazujemy na istniejącą pamięć.

[AnonimoweLwiatko]

Problem ten sam co przy referencjach, nie da się sprawdzić, czy wskazujemy na istniejącą pamięć.

@Gerax9: Is null/nullptr? Chyba chodzi Ci o to czy pamięć na którą wskazuje nie została ponownie wykorzystana, wypełniona losowymi danymi ale nie jest pusta co może spowodować jakiś undefined behavior (co powinno być wzięte pod uwagę podczas implementacji, duh)

@MamCieNaHita

sharedptr nie jest gównem, jest ostatecznością

Jest to kwestia dyskusyjna, w niektórych projektach użycie sharedpointera

[G.....9]

@AnonimoweLwiatko:

nie jest pusta co może spowodować jakiś undefined behavior (co powinno być wzięte pod uwagę podczas implementacji, duh)

Trudno o to w dużym projekcie i dużym zespole.

Jak rozwiązałbyś problem dynamicznie tworzonego obiektu z którego korzystać będzie wektor obiektów.

Dlatego powstał ten wpis. Jeżeli chromium zbanowało shared_pointer to musi być jakieś obejście.
unique_ptr + get, albo new/delete?

[AnonimoweLwiatko]

@Gerax9: No, obejście. Napisanie #!$%@? wrappera na smart_pointer który będzie robił to samo czyli raw + observer + counter ( ͡º ͜ʖ͡º)

Pracuje w sporym zespole i projekcie i nadal używamy shared pointerów więc pierwsze słyszę o takich trendach

[patrolez]

@Gerax9: shared_ptr jest czymś w stylu rzucania kawałka mięcha do wybiegu tygrysów, w którym oczywiście kawał mięcha to pewien wskazywany obiekt, a wybieg tygrysów, to alegoria kodu, którego się większość obawia, ale zawsze znajdzie się jakiś pojedynczy magik, który to ogarnia.

Dobry kod jednak to jest taki, do którego nie potrzeba magików, czyli taki, który jest w stanie być zrozumiany przez najlepiej i przedszkolaka. Dobry kod jest jak dobrze zorganizowane gospodarstwo,

[BeginEnd]

Co z konstrukcjami typu std::vector<std::sharedptr<T>> ?

@Gerax9: To zależy jaki masz usecase. Ogólnie jak już @MamCieNaHita napisał to jest ostateczność. Naćpanie sharedptr szędzie żadko pomaga, a często przeszkadza. Na początku mojej kariery, kiedy po ziemi stąpały jeszcze C++11-zaury, sam się nimi zachłysnąłem i bardzo tego żałowałem.

Czym je zastąpić?

Dobrze przemyślaną architekturą. W większości przypadków po prostu da się zrobić kopię. Jeżeli jasno ustalisz, że obiekty nie mogą sobie kitrać