•  

      @europa: smart pointerkiem i do przodu wszystko na stos wskaźniki to zuo

    •  

      @europa: tak powstał właśnie wiedźmin 3 xD

    •  

      @takrodzisiegniew: Dużo ludzi boi się CPP i ma to uzasadnienie, jednym z powodów jest zarządzanie pamięcią, jednak w nowoczesnych wersjach cpp masz narzędzia aby ułatwić sobie z tym min. smart pointery, poza tym dobrze jest wyzbyć się nawyku pakowania wszystkiego do wskaźników i przyjąć sobie RAII do serca. Wiele firm używa tylko ściśle określonej część feature setu języka, przez co redukuje się złożoność kodu. Nie programuję w CPP w pracy nie bijcie plz.

    •  

      @howorang: Polecam książkę "Nawoczesny CPP" czy jakoś tak, symfonie to se możecie...

      +: novopsico, C.....N +2 innych
    •  

      @howorang: o hui, jeszcze gorzej. spierdalam xD

    •  

      @howorang: niezrozumienie me pogłębia się

    •  

      wskaźniki to zuo

      @howorang: ???? Coś ty przylazł z JavaScriptu czy co? Ja ostatnio w C# miałem tyle problemów z wyłapaniem wszystkich możliwych miejsc w których mi zostają jakieś pochowane referencje żeby obiekt został zakwalifikowany przez GC jako usuwalny, że wolałbym już jawnie zrobić delete na wskaźniku z destruktorem czyszczącym zasoby pod spodem.

      Najgorsze w GC jest to, że nawet trudno jest mi czasem powiedzieć czy mi gdzieś spierdala pamięć, bo on czasem działa a czasem nie działa. Może pamięć rosnąć przez 5 min a potem nagle po 5 min zwinie ją do poziomu startowego. I tak siedzę i się gapię czy mi cieknie czy nie. Co więcej - jak ci cieknie i ślad prowadzi do frameworka lub środowiska uruchomieniowego to jesteś literalnie w dupie. Albo ktoś to kiedyś naprawi albo w tej dupie pozostaniesz. No i my tutaj właśnie pozostaliśmy w jednym starym projekcie Silverlighta który M$ oszczał kilka dobrych lat temu i wycieki jak były tak są nadal.

    •  

      Nie programuję w CPP w pracy nie bijcie plz

      @howorang: Nawet nie programujesz w CPP a coś narzekasz na wskaźniki xD Ah te dzieci języków z Garbage Collectorami.

    •  

      @howorang: Wiesz, widziałem już tylu "pHrOGrAmisTUff" co płaczą na wskaźniki i uważają, że tylko zwierzęta piszą w językach bez GC a C++ nawet nie tykali bo są zbyt dobrzy na języki tak niskiego poziomu i nie chcieli się zniżać do poziomu zwierząt (xD), że jak widzę jak ktoś narzeka na wskaźniki to automatycznie biorę nóż do ręki xD

    •  

      @Khaine: jebac te wasze dzikie znaczki << cout itp, tylko prawilne System.out.println()

      pokaż spoiler ( ͡° ͜ʖ ͡°)

      +: Salpinx
    •  

      @Khaine: no fajnie zrobilbys delete ale to nie znaczy, ze twoje referencje by magicznie zniknely xD problemem w twoim kodzie jest bajzel i referencje do obiektu ktory jest niepotrzebny, a nie brak delete...

    •  

      @europa: Deadline ciśnie - szystkie gry na 25 grudnia bez możliwości obsuwy! W końcu rozumiem, skąd tyle bugów.

    •  

      @XpedobearX: widzisz w Javie nie ma takich problemów i się nie pomylisz ( ͡° ͜ʖ ͡°)

    •  

      @Khaine: Aha, czyli lepiej żeby wisiały sobie dangling pointery xDDD. Weź lepiej nie programuj, a już na pewno nie w takim niebezpiecznym gównie jak C++.

    •  

      no fajnie zrobilbys delete ale to nie znaczy, ze twoje referencje by magicznie zniknely

      @filozof900: W tym wypadku problem był taki, że obiekt który chciałbym aby został usunięty trzymała referencja na obiekt który nawet o nim nie wiedział. Ten drugi chciałbym aby został bo był singletonem a ten pierwszy mogłem spokojnie wypieprzyć, bo nie był powiązany z niczym innym. GC usunął ten obiekt dopiero jak znullowałem tę referencję i oderwałem od wszystkich aktywnych obiektów (i chwilę mi zajęło szukanie która to dokładnie była, bo początkowo myślałem że jakiś event nie odpięty). Nie da się przecież dać znać "e, wywal ten obiekt, już mi nie jest potrzebny" i ta referencja by wtedy zginęła razem z nim - muszę ucinać rączki a potem sprawdzać czy uciąłem wszystkie. W tym konkretnym wypadku akurat delete by rozwiązał problem, bo to obiekt usuwany miał w sobie referencję na obiekt nie-usuwany a nie odwrotnie. To bardzo rzadkie sytuacje, ale zdarza się (szczególnie przy aplikacjach z GUI gdzie widoki się doczepia do obiektów kontekstu), że chciałbym powiedzieć GC aby znukował jakieś gówno.

      Aha, czyli lepiej żeby wisiały sobie dangling pointery

      @Qwertylion: Nie wisiałby dangling pointer. 2 lata programowałem w C++ i pilnowałem wskaźników. Tam gdzie manualnie deletowałem obiekty wcześniej niż w destruktorze to zawsze je nullowałem i sprawdzałem na nulle.

    •  

      @Khaine: ale wiesz ze GC tak nie działa ? To nie ma znaczenia czy obiekt który chcesz usunąć na coś wskazuje czy nie, liczy się to co wskazuje na niego.

    •  

      @Passer93: Tak i w tym wypadku prawdopodobnie bindingi były pod spodem które zrobił framework aby monitorować stan obiektu. Teoretycznie ten singleton nie powinien wiedzieć nic na ten temat, ale framework cośtam podrutował pod spodem widocznie.

    •  

      @Khaine: witam w świecie aplikacji biznesowych, krainie tysiąca bibliotek i frameworkow gdzie programista nad niczym nie ma kontroli we własnej aplikacji. Ale w 90% środowisko wystarcza do pisania crudow a pamięć i tak jest tania

    •  

      krainie tysiąca bibliotek i frameworkow gdzie programista nad niczym nie ma kontroli we własnej aplikacji

      @Passer93: ¯\_(ツ)_/¯ dlatego właśnie mówię, że C++ i jego wskaźnikologia nie jest taka zła, przynajmniej masz kontrolę nad tym co się dzieje.

    •  

      @Khaine: twoim problemem nie jest GC tylko że nie wiesz co gdzie trzyma referencje do obiektów które wymagają sprzątania oraz to że te referencje są silne kiedy najwyraźniej powinny być słabe. Z tego co piszesz to masz tam ostro nasrane w tej aplikacji.

      Wiń framework, nie język. Jakbyś w C++ ten obiekt posprzątał a potem framework wywalił segfault bo gdzieś tam jeszcze pamiętał wskaźnik do posprzątanego obiektu i postanowił go zdereferować to też byś mówił że język to gówno czy raczej że framework jest do dupy?

    •  

      @Khaine: wydaje mi sie, ze wlasnie nie rozumiesz tego do konca. niezaleznie czy pracowalbys w c++ czy w javascripcie, referencje ktore gdzies tam masz nadal bylyby problemem. moglbys usunac obiekt ale sam fakt, ze masz gdzies te referencje swiadczy o braku porzadku w kodzie. skoro nawet nie wiesz co tych referencji uzywa to tym bardziej nie wiesz, co by sie stalo gdybys usunal obiekt. prawpodobnie dostalbys po prostu segmentation fault i dopiero wtedy bys sie drapal po glowie co sie zadzialo ;-)

    •  

      @Khaine mnie uczono kto nie assembluje, ten nie je, a was się uczy wysoka abstrakcja ułatwia analizę tfu

    •  

      @DizzyEgg: No już bez przesady żeby schodzić aż do asemblera, gdzie i tak zazwyczaj nie napiszesz tego lepiej niż kompilator przetłumaczy. Dowaliłem się tylko do tego, że "wskaźniki to zło", bo to właśnie między innymi wskaźniki tworzą z C++ język mający taką a nie inną wydajność, bo zwalniasz i alokujesz pamięć jak chcesz, kiedy chcesz i masz pełną kontrolę nad tym kiedy powstają i giną instancje obiektów. Co nie zmienia faktu, że overhead smart pointerów jest na tyle mały, że w sumie nie ma powodu aby z nich nie korzystać.

    •  

      @Khaine: od wielu lat żaden szanujący się programista cpp nie używa raw pointerow do kontroli ownershipa, jest to po prostu zła praktyka. W mojej firmie narzędzia analizy kodu od raz wykrywają jak jakiś delikwent chce przemycić new albo delete i chronią go przed publicznym upokorzeniem w code rewiew xD
      Wskaźniki to tworzą język C, Cpp to zupełnie inna bestia, jak już to RAII tworzy cpp

    •  

      W tym konkretnym wypadku akurat delete by rozwiązał problem, bo to obiekt usuwany miał w sobie referencję na obiekt nie-usuwany a nie odwrotnie

      @Khaine: jeżeli obiekt usuwany miał w sobie referencję na obiekt nieusuwany to nie ma to żadnego znaczenia z punktu widzenia usuwania obiektu usuwanego. Przecież to byłby jakiś absurd.

      Więc pewnie masz na myśli referencję cykliczną (obiekt usuwany -> obiekt nieusuwany -> (coś) -> obiekt usuwany) ale w tej sytuacji wiń architekta tego genialnego rozwiązania. W C++ na zwykłych wskaźnikach walnąłbyś delete na obiekt usuwany, obiekt nieusuwany nadal miałby na niego wskaźnik i nie miał absolutnie żadnej możliwości żeby sprawdzić że wskaźnik na obiekt usuwany kieruje na śmieci. Całość więc trzyma się na słowo honoru i nadzieję że obiekt nieusuwany tego wskaźnika nie zdereferuje - takie trzymanie się na słowo honoru to jedno z podstawowych źródeł poważnych i trudnych do odtworzenia bugów, zwłaszcza jeżeli weźmiemy pod uwagę że w typowym spaghetti kodzie wspomniane (coś) to może być łańcuszek 20 obiektów.

      To ja już wolę język która zmusza jednak programistę do znalezienia wszystkich silnych referencji i ich wynullowania. Przynajmniej odechce się mu robienia cyklicznych silnych referencji w przyszłości :) Plus JVM pozwala bez problemu przejrzeć całą pamięć, znalezienie nieposprzątanych obiektów to chwila. A zgaduję że przeskanowanie aplikacji napisanej w C++ pod kątem niezdealokowanych wskaźników to jednak wyższa szkoła jazdy (ale nie wiem, pewnie IDE z symbolami debugowania da radę)

      (tzn tak ogólnie to nie jestem super fanem GC bo przynajmniej ten w Javie ma swoje kretyńskie problemy wydajnościowe. Ale na pewno nie jest problemem to że cieknie pamięć gdy geniusze porobią cykliczne referencje. Na smart pointerach też by wyciekła)