On Sat, 22 Nov 2014 13:17:03 -0600, "Pszemol" <P...@P...com>
wrote:

>"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?

Cytat jest taki sobie bo nie mowi ZCO bylo mierzone i w jakich
warunkach

Lepsze zrodlo jest tutaj

http://www.devahead.com/blog/2011/12/coding-for-perf
ormance-and-avoiding-garbage-collection-in-android/

A.L.