[C++] Problem z wskaźnikami współdzielonymi. Nieznana przyczyna wycieku pamięci. 5721 23

O temacie

Autor Wonski

Zaczęty 28.03.2016 roku

Wyświetleń 5721

Odpowiedzi 23

Wonski

Wonski

Gry (themodders@telegram)
radio engineer
posty257
Propsy91
ProfesjaProgramista
  • Gry (themodders@telegram)
  • radio engineer
Cytuj
A jestem pewien że na żadne z wytłumaczeń które podajesz nie masz napisanych przypadków testowych które te potrzeby potwierdzają.

Jeżeli chodzi o obsługę wyjątków to fakt, nie mam napisanego kodu, który by to sprawdzał. Ale to jest projekt, który myślę, że w miarę logiczny i sensowny sposób odwzorowuje charakterystykę pracy z wskaźnikami.
Np teraz jest problem ze wskaźnikiem... z niewiadomej dla mnie przyczyny gdzieś wywaliło poza zakres i nawet na debuggerze nie mogę tego znaleźć.
Zresztą etap prototypu i podstawowej struktury projektu to raczej nie czas na implementację obsługi błędów. Dobrze mówię? A zawsze warto zabezpieczyć się przypisaniem do tego nullpointera.
Czy to rzeczywiście jest aż tak bezsensowne rozwiązanie?

Wszędzie czytałem, że gdy aplikacja ma bugi to jeszcze pół biedy, ale jak już ma crashe to jest katastrofa.
Zaplanowanie obsługi tego gówna już na etapie konstrukcji podstawowej struktury to raczej dobre rozwiązanie, tak?

Co do TDD to skoro polecasz to raczej nie na darmo, więc poczytam, dzięki.

 

inż. Avallach

inż. Avallach

Administrator
posty7707
Propsy5234
NagrodyV
ProfesjaProgramista
  • Administrator
Planowanie takich rzeczy już na etapie konstrukcji podstawowej struktury to okropny błąd. Nadgorliwość jest gorsza od faszyzmu - w programowaniu to szczególnie prawdziwe. Nie pisz kodu dopóki nie będziesz pewien (najlepiej dzięki testom jednostkowym) że jest on niezbędny. Inaczej tylko utrudniasz sobie dalszą pracę. Pamiętaj że każdy dołożony kawałek kodu trochę utrudnia rozumienie i rozwijanie całości. Każdy dołożony *nieotestowany* kawałek kodu może *znacząco* utrudniać zrozumienie i rozwijanie całości. A ty nie masz żadnych testów jednostkowych i prawdopodobnie masę niepotrzebnego i potencjalnie zabugowanego kodu. Nie jestem w stanie znaleźć na oko gdzie leży problem, debugować nie mogę ze względu na brak odpowiedniego środowiska.

Wonski

Wonski

Gry (themodders@telegram)
radio engineer
posty257
Propsy91
ProfesjaProgramista
  • Gry (themodders@telegram)
  • radio engineer
Jeżeli dobrze Cię zrozumiałem....

Mam zaplanowaną hierarchię klas np w UML, przypuśćmy, że jest to model agregacji (nie przepadam za dziedziczeniem, agregacja wydaje mi się bardziej naturalna/intuicyjna, no chyba, że mówimy o implementacji wzorców projektowych to wtedy jest odwrotnie )

Jak to budować już w kodzie?
Wpierw zaczynam od najbardziej podstawowego elementu (klasy elementarnej), wykonuję testy jednostkowe dla niego i jeżeli upewniłem się, że wszystko jest ok to mogę przystąpić do następnego etapu roboty, tak?
I już za pomocą samych testów jednostkowych określam, jakie konkretne elementy są narażone na ewentualne crashe i tam implementuje obsługę błędów już jako końcowy etap budowy tego typu, tak? Jeszcze testy czy obsługa błędów działa tak jak powinna i jazda dalej..

Wydaje się to być bardzo naturalne podejście do problemu, jeśli oczywiście dobrze zrozumiałem.

Dlatego lubię zakładać tutaj tematy. Nawet gdy nie rozwiążę problemu to i tak nauczę się czegoś pożytecznego  :)
 

inż. Avallach

inż. Avallach

Administrator
posty7707
Propsy5234
NagrodyV
ProfesjaProgramista
  • Administrator
Miałbym dużo do napisania. Może zacznijmy od tego:
Cytuj
Wszędzie czytałem, że gdy aplikacja ma bugi to jeszcze pół biedy, ale jak już ma crashe to jest katastrofa.
To zależy od rodzaju aplikacji, tego jak ważne jest jej nieprzerwane działanie i bezbłędność wyników.
W wielu przypadkach jest na odwrót niż piszesz - crash może być niewielkim problemem i szybko i bardzo wyraźnie dawać znać co jest nie tak i że trzeba to naprawić. "Ciche" błędy mogą mieć o wiele gorsze skutki - przykładowo zapisywanie tylko części edytowanego dokumentu, ujawnianie danych innych użytkowników, nadpisywanie istotnych informacji itd. Czasami crash jest ostatnią deską ratunku mogącą zapobiec wystąpieniu błędu który byłby destrukcyjny i przez to dużo bardziej od niego kosztowny.

Testy jednostkowe nie służą do zabezpieczania się przed crashami. Służą przede wszystkim do ustalania tego jak w najprostszy (a więc zazwyczaj najlepszy) sposób osiągnąć cel, a także do "ochrony" poprawności kodu który już stworzyłeś. Ochrony przed zmianami psującymi go, tak abyś mógł swobodnie bez jakiegokolwiek strachu wprowadzać takie zmiany które go nie psują.

W UML nie musisz planować klasy dokładnie, ze szczegółami. Dokładne interfejsy między bytami mogą wyewoluować naturalnie, w miarę tego jak stają się potrzebne. Staraj się nie pisać ani linijki zanim nie jest ona niezbędna do tego żeby jakiś test który obecnie się nie kompiluje lub nie przechodzi zaczął przechodzić. Bardzo polecam serię Clean Code - jest w części poświęcona TDD. Odcinki są drogie jak na studencką kieszeń, ale zapewne zgadujesz gdzie można dostać je bez opłat.
Z czasem zacznie ci to przychodzić naturalnie, nawet bez pisania testów z góry. Po prostu zaczniesz zauważać że pisząc coś "na zapas", zanim jest to użyte, często będziesz musiał dużo w nim zmieniać kiedy użycie już się pojawi. Sam się dużo razy o tym przekonałem. Czasami interfejs klasy zaplanowany bardzo logicznie i bez widocznych problemów okazuje się po prostu nie pasować do zastosowania które programuje się dopiero później. Trzeba go zmieniać, nieraz dużo kodu leci do kosza. Lepsze efekty osiąga się stosując odwrotną strategię - najpierw pisząc użycia, a dopiero później na ich podstawie klasę która je zaspokoi.


0 użytkowników i 1 Gość przegląda ten wątek.
0 użytkowników
Do góry