[G.....9]

Jak powszechnie wiadomo shared_ptr to g---o. 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

[F.....n]

@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,

[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)

[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

[AnonimoweLwiatko]

@Gerax9: No, obejście. Napisanie p----------o 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, w którym krówki mają swoje stanowiska i każda ma indywidualny dostęp do koryta.

Oczywiście mowa o rozpiętym i dużym kodzie. Koryto to alegoria podejścia Event-Driven, albo Message-Queue, albo Dependency-Injection z uwzględnieniem tzw. life-cycle, w którym właścicielem jest obiekt nadrzędny, który komponuje układ krócej żyjących obiektów, czy też

[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ą