On 11.07.2013 02:10, bartekltg wrote:
> W dniu 2013-07-11 01:50, Michoo pisze:
>
>> Brak GC (czy fakultatywny GC jak w pythonie) nie oznacza brak menagera
>> pamięci. Można by spokojnie zrobić system/język/framework z
>> deterministycznym zarządzaniem pamięcią a jednocześnie kompaktowaniem
>> sterty, optymalizowaniem rozłożenia obiektów pod względem cache/etc.
>> Oczywiście wykrywanie cykli musi jakoś być rozwiązane czy to przez
>> zmuszenie programisty do używania week-reference (cykl==terminate nauczy
>> bardzo szybko) czy przez wykrywanie cykli (vide python).
>
> To terminate z powodu cyklu to na pewno dobry pomysł?
>
> Czasem zmusi to do zupełnie niepotrzebnego obchodzenia,

Tak. Jest to cena którą płacisz za deterministyczne sprzątanie śmieci.
GC też zazwyczaj daje też dużą wolność a w praktyce czasami zmusza do
zupełnie niepotrzebnego obchodzenia - nie ma rozwiązań do wszystkiego
idealnych.

> np w jakimś algorytmie na grafie skierowanym głownie usuwającym
> krawędzie.

Jak to robiłem w C++ to aby z jednej strony nie bawić się w ręczne
new/delete a z drugiej nie cieknąć pamięcią miałem w obiektach
opakowujących algorytmy std::vector<shared_ptr<T> > freeMeLater a sam
algorytm działał już na wskaźnikach. Było szybkie i dawało gwarancję, że
w momencie gdy dane przestaną być używane wszystko się ładnie sprzątnie.


>
>
>> Tak jak się zrobił w pewnym momencie hype na noSQL tak może i przyjdzie
>> czas na noGC. Może się nawet coś dobrego z tego wykluje.
>
> A ludzie od c++ w większości tak nie mają?

Ludzie od C++ w większości muszą pamiętać o pamięci. Użytkownicy GC w
większości nie muszą. Mi chodzi o to, żeby pamiętać jedynie o nie
zepsuciu pamięci (być może za cenę dodatkowego wektora tu i uwdzie[*]) a
reszta się zrobi sama.

[*] Zauważ, że w języku to może się robić automatycznie na zasadzie np
operatora lNew który tworzy obiekt i wiąże jego czas życia z opakowującą
funkcją czy klasą.

--
Pozdrawiam
Michoo