Dlaczego programiści C++ mają alergię na termin Garbage Collector?

Cześć,

Czytając czy słuchając różnych wypowiedzi programistów języka C++ odnoszę nieodparte wrażenie, że środowisko to ma poważną alergię na termin Garbage Collector. Do tego stopnia, że zliczanie referencji wyrzuciło poza nawias strategii odśmiecania, aby tylko z terminem odśmiecania nie mieć nic wspólnego. Trochę to śmieszne a trochę straszne, bo śledzone wskaźniki pomagają w rozwiązywaniu niektórych problemów, więc jako opcjonalne lepiej byłoby je mieć niż nie mieć. Zastanawiałem się, czy ta niechęć skierowana jest tylko w odniesieniu do globalnego mechanizmu odśmiecania, analogicznego do tego dostępnego w języku D, ale po obejrzeniu prezentacji Herba Suttera dotyczącej grafów i pomyśle na wskaźnik deferred_ptr dochodzę do wniosku, że niechęć środowiska do potencjalnego mechanizmu odśmiecania jest niezależna od tego, jak taki mechanizm miałby działać.

Co o tym sądzicie?

To nie tak, że mają alergię na GC, tylko tam gdzie jest sens używania C++ najczęściej GC nie ma zbytnio racji bytu (a przynajmniej niedeterministyczny GC). Ref-count jest w pewnym stopniu deterministycznym GC, co jeszcze się mieści w "akceptowalnych ramach". Jak masz możliwość użycia języka z GC, to C++ najczęściej nie będzie miał sensu.

@hauleth:

Prawda.

Skądinąd szkoda, jeden z niewielu jezyków, że mozna podmieniać new jako zestandaryzowany proces bez hakerki.
Widywałem w necie, te i ów podobno zrobił i używał C++ GC, ale to widziene przez ramię.

Ja tam nie mam alergii, ale z reguły GC to dodatkowy kod do wykonywania a nie ma na tyle zasobów, żeby go puszczać.

To dlatego język o idealnej wręcz składni czyli D nie zdobył popularności bo posiadał GC który można było wyłączyć w ekstremalnych sytuacjach skierowanych na szybkość.

Bo kupa stosów ma po 10-20 lat i nikt tego nie będzie przepisywał bo D ma GC. Zobacz na Rust jak powoli się przyjmuje. z resztą w :dużym"(stb, getway itp.) kupa obiektów zwyczajnie istnieje cały czas i tyle.

Sporo dużych systemów napisanych w C++ ma garbage collector. Ot chociażby silniki gier takie jak unreal engine. I często są z tym spore problemy wydajnościowe.

Tak 25 lat temu byłem wielkim miłośnikiem C++ i pisałem w zasadzie tylko z użyciem własnego GC (domowej roboty, okropny RC - ale działał mi ok).
Problem 1 - nie było standardu,
Problem 2 - używanie gc, const Ref, stl, powodowało, że byłem bardziej samotny niż programista funkcyjny w javie.
(od tego czasu troche się C++ zmieniło, ale community jest "rozstrzelone" - od void* do funkcyjnego C++ z kosmicznymi templatami, przynajmniej tak to widać z daleka)

Z tego co rozumiem, dla niedeterministycznych GC znaczącym problememem są destruktory. Java miała finalize(), ale w sumie nie było gwarancji jego użycia, D ma taki zapis:

The garbage collector is not guaranteed to run the destructor for all unreferenced objects. Furthermore, the order in which the garbage collector calls destructors for unreferenced objects is not specified. This means that when the garbage collector calls a destructor for an object of a class that has members which are references to garbage collected objects, those references may no longer be valid. This means that destructors cannot reference sub objects.

W C++ nie do pomyślenia jest aby destruktor obiektu był wykonany inną liczbę razy niż 1, a w czasie jego wykonania obiekt był w innym stanie niż poprawnym do normalnego działania.

Osobiście chętnie bym widział ustandaryzowany sensowny GC w C++, ale patrząc na to, jakim fiaskiem zakończyło się dodanie API GC do C++11 (usunięto kilka standardów później, 0 implementacji), to nie wróżę sukcesu.

dochodzę do wniosku, że niechęć środowiska do potencjalnego mechanizmu odśmiecania jest niezależna od tego, jak taki mechanizm miałby działać

Jeżeli masz na myśli odśmiecanie znane z VMek javy czy .net, które potrafi "zatrzymać świat" to nawet ciężko się dziwić, bo C++ to nie lekkie bzduro apki na desktopie ani jeden z kilku procesów na serwerze, który jak nie wyrabia to zostanie automatycznie ubity i zastąpiony nowym. Wyobrażasz sobie sprzęt medyczny, który się zatrzymuje całkowicie na kilka/kilkanaście sekund, żeby sobie pamięć zwolnić? Albo "autopiloty" w samochodach, można by dodać status dla kierowcy żeby przynajmniej wiedział dlaczego złamał kręgosłup w wypadku breaking will start shorty, please wait... :D

Poza tym taka całkowita niechęć i opór to też nie do końca prawda. Memory Arena czyli idea by zaalokować więcej pamięci na później i pogodzenie się z jakimiś tam wyciekami by nie prosić się systemu o pamięć co chwile to jednak dość popularna technika tam gdzie zasoby na to pozwalają.

@several:

który się zatrzymuje całkowicie na kilka/kilkanaście sekund

ile?? src?

Your GC algorithm has a major influence on the GC pause time. If you are a GC expert or intend to become one (or someone on your team is a GC expert), you can tune GC settings to obtain optimal GC pause time. If you don’t have a lot of GC expertise, then I would recommend using the G1 GC algorithm because of its auto-tuning capability. In G1 GC, you can set the GC pause time goal using the system property ‘-XX:MaxGCPauseMillis.’