[s_theCapt]

Mały kod: https://pastebin.com/y8tNpFtA

Nie wiem czy tak się da? Tworzę shared pointer, czyszczę listę i zamykam funkcję więc ostatni pointer ginie... czyli i "podmiot liryczny" ginie, ale w którym momencie? Czy coś może pójść nie tak? W programie to nie do końca tak wygląda, ale sytuacja ta sama.

#programowanie #cpp

[koostosh]

@s_theCapt: wygląda wporzo

[Saly]

@s_theCapt: jaki potwór ( ͡° ʖ̯ ͡°) W tym wypadku TaskEnd zabija sam siebie. Jak po steps.clear() odpali się jakiś kod, który będzie uderzał do jakiegokolwiek pola TaskEnd (tutaj chyba tak nie jest, ale mówię o przyszłości, wystarczy, że dodasz jakieś pole np std::string) to będziesz miał UB. Rozwiązanie: kod, w którym nie ma cykli

[vytah]

@s_theCapt: Wygląda ok. Shared pointer będzie sprzątnięty w momencie wywołania clear(), bo clear() niszczy wszystkie obiekty w wektorze.

[s_theCapt]

@Saly: nie zabija sam siebie przy clear(), wcześniej biorę shared_ptr do zmiennej w ciele funkcji, a więc self ginie dopiero po return?

[koostosh]

to jest typowy przypadek "delete this", póki po steps.clear nie robisz nic z tym obiektem to jest ok. Według mnie nawet nie musiałeś robić tej kopii.

[Saly]

@s_theCapt: mój błąd. Tak czy owak ten kod to pole minowe, nie powinno się zabijać samego siebie w własnej metodzie. Wystarczy, że odpali się jakiś destruktor, który coś będzie chciał zrobić z pamięcią obiektu i dupa. Na pewno lepiej byłoby to inaczej zaprojektować

[lionbest]

@Saly: @vytah: Przyjrzycie się, on robi kopie auto ptr, czyli obiekt zniknie dopiero po zwinięciu stosu i to w wypadku kiedy wywoła na referencji do elementu pola steps, a nie kopii tego shared_ptr.

@s_theCapt: Metoda, która niszczy swój obiekt, na którym jest wywoływany to antywzorzec.

[Saly]

, a więc self ginie dopiero po return?

@s_theCapt: tak, ale po tym usunięciu ptr dalej odpalają się destruktory zmiennych lokalnych będących przed ptr. Czy to jest legalne: szczerze nie wiem, na pewno jest to brzydkie. Przykładowo wystarczy, że ktoś bez dogłebnęgo czytania kodu doda jakiś mutex przy użyciu std::lock_guard na samym początku funkcji.


@lionbest: tak, nie doczytałem

[s_theCapt]

@lionbest: moim takim eksperymentalnym "wzorcem" jest to, że "wszystko jest krokiem" i cała appka sobie chodzi kolejkując i odpalając te kroki więc sobie zrobiłem czyszczenie też w taki sposób. ( ͡º ͜ʖ͡º) w programie właściwym, exec() jest prywatną funkcją wywoływaną tylko z jednego miejsca, statycznej funkcji exec_next()

[s_theCapt]

@lionbest: pewnie nie pamiętasz, ale pomogłeś mi na wykopie już kilka razy więc szanuję twój autorytet xD i jeżeli to co napisałem cię nie przekonuje w ogóle, to to zmienię :D

[lionbest]

@s_theCapt: Zazwyczaj z exec zwraca się jakiś status i po nim rozpoznaje jakie operacje zrobić na danym obiekcie.

[s_theCapt]

@lionbest: tak, ale chciałem żeby stepy to były subclassy i mieć te operacje w takim miejscu, z innymi dla każdego stepa zmiennymi i operacjami dodatkowymi, bo inaczej to jedyne co widzę to jakieś niepotrzebne potem rozpoznawanie po tym statusie, potem jeszcze cast do odpowiedniej klasy i subklasy jeszcze tych kontrolerów... strasznie dużo kodu, albo źle to widzę... a chcę to wykorzystać w przynajmniej dwóch programach jakie mam, więc zupełnie inne mają

[lionbest]

@s_theCapt: Sterowanie elementami klasy Task powinno należeć do jej samej, więc wywoływanie steps.clear() z innej klasy jest złym nawykiem. Teraz zwróciłem uwagę, że pole jest prywatne i nie ma dostępu z Task_end, więc przykład jest błędny. Możliwości sterowania pętlą Stepów w Tasku też nie powinieneś mieć tak znowu dużo.

[s_theCapt]

@lionbest: tak, przykład jest błędny, w programie mam friend class. No i jasne, ale czy tworzenie dodatkowej funkcji Task::clear_steps i wywoływanie jej tylko po to żeby zachować hierarchię ma sens? Zawsze się przecież np. z jakiegoś gui czy z powodu jakiegoś zdarzenia w silniku robi jakieś operacje, klasy ze sobą rozmawiają. ( ͡° ʖ̯ ͡°)

[lionbest]

@s_theCapt: Oczywiście że tworzenie jasno określonego interfejsu jest leprze niż upublicznianie prywatnych zmiennych.