On 02/10/2011 01:59 AM, Lelek@ wrote:
>
> "Jacek Radzikowski" <j...@s...die.die.die.piranet.org> wrote in
> message news:iivmnj$f55$1@inews.gazeta.pl...
>>> To nie jest aż tak bez sensu, bo casting signed byte to sign integer
>>> kopiuje 8-my bit do 31-go a właściwie rozszerza np (int)0x80 -> FFFFFF80
>>> bo signed a nie 0x80 :-)
>> A fakt. Zasugerowałem się typem buf i przyjąłem że bfx też jest typu
>> byte :)
>
> Ta Java to jeden wielki shit :-) Jak się operuje na strumieniach danych

Shit bo nie umiesz się nią posłużyć. Napisałem w javie dobrych
kilkadziesiąt tysięcy linii i uważam że jest to całkiem przyjemny język.
Inne języki też znam, więc mam porównanie.

> binarnych to w kółko trzeba konwerować to co zwracają funkcje w byte
> signed do signed int ale wymaskowywać je. Idiotyzm.

Nie bardzo wiem o co chodzi, ale mam wrażenie że usiłujesz zrobić coś na
około.

> Nie wiem, na razie działa z tym testem czy len jest 0 czy nie, twoich
> rad nie umiem zastosować. Nie rozumiem jak mam deklarować ten sam bufor
> wiele razy :-) Przeglądam od 10 dni już to co ludzie piszący w javie
Jak powiesz czego nie rozumiesz, to może będę mógł Ci pomóc. Na razie
widzę że walczysz z samą ideą obiektów.
Bufora nie deklarujesz kilka razy. Samą zmienna buf deklarujesz raz, w
takim miejscu żeby była widoczna ze wszystkich miejsc w których musisz
się do niej odwoływać (ale bez przesady. Najprawdopodobniej wystarczy ze
zadeklarujesz ją lokalnie w funkcji).
Buf w twoim przypadku przechowuje nie sam obiekt, a referencję do niego
(referencja działa troszkę podobnie jak wskaźniki w C, choć to nie do
końca jest to samo). Funkcja FromEditText.getBytes() sama alokuje pamięć
na tablicę zawierającą wynik i zwraca Ci wskazanie na nią. Ta referencja
jest wpisywane do zmiennej buf. Jeśli przed wywołaniem funkcji było w
niej coś innego, poprzednia wartość jest tracona, a w jej miejsce jest
wpisywana wartość zwracana przez przez getBytes. Nie następuje tam żadne
przepisywanie tablic (dlatego nie trzeba wcześniej alokować pamięci).

Wszelkie operacje jakie wykonasz na zmiennej buf po wpisaniu do niej
wartości zwróconej przez getBytes będą wykonywane nie na twojej tablicy,
a na tablicy zaalokowanej wewnątrz funkcji.
Sprawdzanie warunku buf.length jest potrzebne po to, żeby nie tworzyć
tablicy o zerowej długości (przypisanej do bfx).

> wyprawiają. Dokładnie robia to jakby zaczynali progframować w bascomie i
> nie rozumieją co czynią :-)
Może to ci, którzy przesiadają się na jave z bascoma :) Ja też widziałem
dużo śmieci, ale też bardzo dużo kodu bardzo dobrej jakości.

> Z tego co się dowiedziałem to Java powstała bo ludzie nie rozumieli
> wskaźników i zapominali o zwalnianiu zaalokowanych zasobów :-)
Nie tyle zapominali, co woleli się skupić na rozwiązaniu problemu
zamiast babrać się z gospodarką pamięcią. Operując na wskaźnikach bardzo
łatwo z prostego programu stworzyć koszmarek - java stara się do tego
nie dopuścić (a przynajmniej nie przez jeżdżenie po pamięci). Mając do
dyspozycji dużo wolnego ramu, nie trzeba się martwić żeby jak
najszybciej zwolnić przydzielony a nieużywany obszar. Ręczna gospodarka
przydzielaną pamięcią w bardziej skomplikowanych projektach może
przypominać chodzenie po polu minowym. Nic dziwnego że nawet najlepszym
i najbardziej uważnym programistom zdarza się popełnić głupie błędy,
typu nie zwalnianie czegoś czy wielokrotne zwalnianie.
Mechanizm odzyskiwania nieużywaniej pamięci jest implementowany w wielu
językach wysokiego poziomu. Java jest tylko jednym z nich.

pzdr.
j.