Sens Garbage Collector'a

Mam takie pytanie - dlaczego Garbage Collector jest tak powszechny? Czy nie prościej i optymalniej wydajnościowo byłoby wyznaczać punkty usuwania zmiennych, po miejscach ostatnich odwołań do nich, już w trakcie kompilacji/przetwarzania na kod do VM?

prościej i optymalniej wydajnościowo byłoby wyznaczać punkty usuwania zmiennych, po miejscach ostatnich odwołań do nich, już w trakcie kompilacji

Owszem, używa się tego. Zmienne lokalne są wrzucane na stos, żeby szybko, prosto i hurtem je usunąć. Nawet Java nie alokuje dynamicznie takiego najprostszego inta. W przypadku, gdy alokacja dynamiczna już zachodzi, zwykle nie da się określić, kiedy należy coś usunąć na podstawie samej statycznej analizy kodu. Zwróć zaalokowany obiekt z funkcji i już się robi problem, bo alokujesz, a nie usuwasz. Z kolei odbierając referencję z funkcji też nie wiesz, czy możesz to usunąć, bo może zachodzić jakieś współdzielenie. Co można wkompilować, to zliczanie referencji i na podstawie tego stwierdzać, czy można po obiekcie pozamiatać.

Czy nie prościej i optymalniej wydajnościowo byłoby (...)

Akurat wydajnościowo bardziej optymalne jest nie zwalnianie obiektów - stąd te dobre wyniki czasowe niektórych algorytmów napisanych w Javie. Oczywiście ma to swoją wadę w postaci większego zużycia pamięci i samego procesu odśmiecania (IMO brak możliwości deterministycznego niszczenia obiektów to wada).

Świat buduje rozwiązania w oparciu o GarbageCollector i działają, więc... chyba nie ma sensu aż tak głęboko wnikać w temat.

C# czy też Java są znacznie lepsze, jeżeli chcesz szybko stworzyć aplikację. Tu nie chodzi o to czy jest Garbage Collector, tylko czy masz do dyspozycji całą masę bibliotek na sensownych licencjach oraz ile energii trzeba włożyć, aby zacząć z takiej biblioteki korzystać.

Ostatnio koduję sporo w C# i instalacja nowej biblioteki zajmuje poniżej minuty.
Instalacja biblioteki pod linuxem dla C/C++ jest relatywnie szybka.
Kompilacja bibliotek C++ pod Windowsem to już jest proces czasochłonny.

Znalezienie bezpłatnych bibliotek na licencji umożliwiającej development komercyjny też jest w C++ upierdliwe. Większość bibliotek do C++ ma API języka C. Taki C# czy Java zrobili w praktyce sensowne i intuicyjne wrappery na czytanie PDF-ów, plików graficznych i innych pierdół. W C++ tego nie ma (albo jest na słabym poziomie).

W C# się szybko wytwarza kod, bo masz gotowe klocki i kilkoma linijkami składasz je w całość. W C++ napisanie WebService-a to długi proces. W C# zrobisz sensownie działający serwis w jeden dzień.

C++ ma sensowną alternatywę dla GarbageCollectora i jest nią używanie std::shared_ptr. Tak więc nawet jeżeli udowodnisz, że GarbageCollector jest gorszy niż możliwości C++ to i tak nie zmieni to sytuacji na rynku, bo wszystko rozchodzi się o czas dostarczania rozwiązań, a nie o ich wydajność (czytaj: C#/Java zużyją 4x więcej ramu? Spoko - dorzucimy RAM do serwera jeżeli w ogóle zajdzie taka potrzeba).

Garbage Collector z jednej strony to genialne narzędzie a z drugiej mało "kontrolowalne". C++ z użyciem smart pointerów jest genialny ale jednak wymaga to jakiejś lepszej znajomości tego języka. C# miał być z założenia łatwiejszy i taki też jest. Czasem na forach widzę, jak fanboye C++ wmawiają innym, że C# jest dużo gorszy bo łatwiejszy, wszystko dzieje się poza naszą wiedzą etc etc. Prawda jest taka, że to co C# ma zaimplementowane i tak prędzej czy później trzeba by było zaimplementować do C++. Okej, smart pointery są dobrą alternatywą ale mało ludzi ma chęć zwracania na to cały czas uwagę, jak mogą wybrać GC i mieć to gdzieś.

Dodam jeszcze do tego co napisał DejaVu: prawda jest taka, że w C# jedyne co musi umieć programista to znać i rozumieć składnię. Chcesz sobie dodać bibliotekę do projektu? Ściągasz - dodajesz kilkoma kliknięciami i możesz bez problemu korzystać. Chcesz dodać bibliotekę do C++?
a) Wszystko idzie sprawnie, podobnie jak w C# (kilka % przypadków)
b) Undefined reference to...
    - wersja pod inny kompilator
    - zła kolejność linkowanych bibliotek
    - inny błąd związany z systemem
c) Musisz kompilować ze źródeł
    - wszystko idzie sprawnie (kilka % przypadków)
    - Error: "some_other_lib_file.h" - no such file or directory
    - kod nie kompiluje się pod aktualnym standardem
    - kod wymaga n kolejnych bibliotek, które też trzeba samemu skompilować
        - nowe wersje tych bibliotek zostały pozmieniane i dostajesz błędy kompilacji
    - makefile nie znajduje plików innych bibliotek
Ktoś kto długo w tym siedzi sobie poradzi ale biada początkującym - wytłumaczenie instalacji jakiejś biblioteki, która w dodatku była pisana w C, komuś kto nie miał wcześniej z tym styczności prawie na pewno skończy się tym:

On: coś mi nie działa stary
Ty: jaki błąd dostajesz
On: Undefined reference...

c) Musisz kompilować ze źródeł     - wszystko idzie sprawnie (kilka % przypadków)

Z tymi kilkoma procentami to nie przesadzałbym. Powiedziałbym, że większość bibliotek kompiluje się bez problemów, o ile została pisana pod dany system.

PS. widzę, że wątek z dyskusji o GC zamienia się powoli w dyskusję "C/C++ vs reszta świata".

Dlatego pod Windowsem jest to kilka % ;)

Okej, smart pointery są dobrą alternatywą

Nie są. Tak wygląda alokacja pamięci w typowym generacyjnym GC: . Porównaj to z dowolną implementacją malloc.