"A.L." <a...@a...com> wrote in message
news:ifm17a961q00ft2i33ag4otoe0jl4d84nl@4ax.com...
>>Czy autor tych słów na ktore się tu powołujesz jest dla Ciebie jakimś
>>autorytetem?
>>Bo nie przytoczyłeś źródła tej wypowiedzi - może autor nie wie o czy mówi?

Zero komentarza?

>>Ja mam ponad 20-letnie doświadczenie w programowaniu w C/C++ i żadna
>>pamięć
>>w moich programach nie wycieka...
>
> To jeszcze ciekawe jakie to sa programy

Głównie jest to embedded computing (nie pecety).

>>Mam pewne przeczucie na podstawie pracy w innych językach programowania
>>gdzie nie deklaruje się rozmiaru/typu zmiennej ani nie alokuje się dla
>>niej
>>specyficznego obszaru w pamieci RAM (ale brak bezposredniego
>>doswiadzczenia
>>w Javie)
>
> Java jest akurat jezykiem silnie typowanym. Czy w C/C++ deklaruje sie
> GDZIE w pamieci zmienna bedzie ulokowana? Jakos sobie nie przypominam.

Na pecetach pewnie nie deklaruje się zwyczajowo, choć też można.
Ale na innych platformach często chcesz wiedzieć która zmienna
w której kostce siedzi bo np. ta kostka ma podtrzymanie bateryjne
a druga go nie ma...

>> ze takie srodowisko promuje szybkie, niechlujne i bezmyslne
>>korzystanie z zasobow pamieci...
>
> Niby dlaczego? Pamiec w Javie alokuje sie tak samo jak w C++.

Jasne. Są pointery/wskaźniki do fizycznej pamięci operacyjnej :-)

> Czas
> zycia obiektu w Javie kontroluje sie pzrez referencje - jak dlugo jest
> referencja do obiektu, tak dlugo nei bedzie on "odsmiecony". Znane sa
> techniki programwoania gdzie obiektow sie nei zwalnia (to znaczy,
> zachowuje sie referencje), a trzyma zbior obiektow do pozniejszego
> wykorzystania. Co parwda, takie techniki stosowano w czasach Javy 1.1,
> teraz sa juz niepotzrebne.

W technice embedded unika się dynamicznej alokacji pamięci
i związanej z nią fragmentacją wolnej pamięci - to są urządzenia
które mają pracować bez restartu/resetu miesiącami, latami
i nic tam nie może się samo w czasie używania "bałaganić"
ani śmiecić żeby trzeba było śmieci zbierać...

Ale oczywiście smartfone nie zawsze można tak zakwalifikować.
Tym dzisiejszym smartfonom bliżej pecetowi niż komputerom embedded.

> Bez odsmiecacza nei da sie efektywnie napisac w miare skomplikowwnego
> programu. Gdy w pewnym momencie mamy zaalokowane, powiedzmy,
> 1000 obiektow i tworaz one skomplikowany graf zaleznosci, reczena
> dealokacja ani nie am sensu ani szans na powodzenie. Zwlaszcza jezeli
> taka struktuar tworzona jest dynamicznie

Ilość obiektów rzędu 1000 jest nieogarnięcia dla jednego człowieka, ale
dla komputera nie stanowią takie liczby obiektów żadnego problemu...
Co jest ważniejsze aby ogarnąć strukturę danych programu i stworzyć
jako programista mechanizmy którymi komputer za nas będzie tymi
obiektami zarządzał.

> Zreszta, C++ tez ma "proteze" odsmiecacza - patrz "smart pointers" w
> bibliotece Boost. Powszechnie tez stosowany jest pzrez programistow
> C++ odsmiecacz zwany Boehm garbage collector. Biblioteka taka

Bibliotek różnych i środowisk można dołożyć tysiące i zmienia to
jedynie punkt widzenia dla aplikacji która z biblioteki korzysta...
Ani nie masz gwarancji że ktoś zrobi alokację pomijając bibliotekę
ani nie masz gwarancji że sama biblioteka nie ma jakiegoś robala.

Ale chyba oddaliliśmy się nieco od tematu głównego...
Sugerujesz może że inicjujący ten wątek cytat ma błędy?
Z czymś się nie zgadzasz? Może podsumowałbyś ze swojej strony?