W dniu 2011-02-09 19:59 Lelek@ napisał(a):

>> Skoro ta dyskusja trwa dalej, to zanim się wytoczy takie armaty, można
>> byłoby poprosić autora wątku o kompilowalny kawałek kodu który ma
>> sprawiać takie problemy? Z opisu, z pierwszej wiadomości, można
>
> public void dupa() {
[...]
> Jeżeli w polu EditText nic nie wpiszę, będzie puste to próba odczytania
> buf[0] skończy się wywałką.

Hmmm, coś chyba ściemniasz. Skopiowałem twój przykładowy kod i odpaliłem
w emulatorze 2.2. Na głównej aktywności mam kontrolkę edycyjną o nazwie
"editText1". Tak wygląda cała metoda (podpiąłem jej wywołanie pod
naciśnięcie dodatkowego przycisku):

public void test() {
EditText editText = (EditText) findViewById(R.id.editText1);
String fromEditText = editText.getText().toString();

byte buf[] = new byte[256];
int bfx[] = new int[256];
int i, len;

try {
buf = fromEditText.getBytes("UTF-8");
} catch (UnsupportedEncodingException e) {
// TODO Auto-generated catch block
e.printStackTrace();
return;
}

len = buf.length;

for (i = 0; i < len; i++) {
bfx[i] = ((int)buf[i] & 0xFF);
Log.d("TEST", "BYTE: " + bfx[i]);
}
}

Znajduje się tu wszystko, co przytoczyłeś plus dodatkowy kod na początku
do odczytania ciągu znaków z kontrolki edycyjnej. Początkowe
zaalokowanie bufora buf nie ma znaczenia bo metoda getBytes() i tak
zwraca tablicę bajtów i zmienna buf zostanie nadpisana. Prościej jest
nie deklarować tej zmiennej na początku tylko dopiero gdy jest
potrzebna, np:
byte buf[] = fromEditText.getBytes("UTF-8");

W każdym razie uruchomienie daje spodziewane rezultaty. Gdy kontrolka
jest pusta to nic się nie wywala, metoda getBytes() zwraca pustą tablicę
a nie null, w zmiennej len mamy wartość 0 i nic się nie wypisuje.

Natomiast gdy do kontrolki edycyjnej wpiszę jakiś tekst to także
powyższy kod działa zgodnie z oczekiwaniami. Na debugu (to ten magiczny
LogCat, w Eclipse możesz go pokazać wybierając z menu: Window/Show
view/Other/Android/LogCat albo prościej naciskając Ctrl+3 i wpisując
"logcat") jest to pokazywane:

02-09 22:04:03.585: DEBUG/TEST(336): BYTE: 97
02-09 22:04:03.585: DEBUG/TEST(336): BYTE: 100
02-09 22:04:03.585: DEBUG/TEST(336): BYTE: 97
02-09 22:04:03.585: DEBUG/TEST(336): BYTE: 109

Chyba nie unikniesz pokazania większego kawałka kodu aby ustalić co się
wywala właściwie. Możesz spakować cały projekt i wrzucić gdzieś na sieć?

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

do góry

"Adam Dybkowski" <a...@4...pl> wrote in message
news:iiv3lq$tqt$1@news.onet.pl...
>W dniu 2011-02-09 19:59 Lelek@ napisał(a):

>
> Znajduje się tu wszystko, co przytoczyłeś plus dodatkowy kod na początku
> do odczytania ciągu znaków z kontrolki edycyjnej. Początkowe zaalokowanie
> bufora buf nie ma znaczenia bo metoda getBytes() i tak zwraca tablicę
> bajtów i zmienna buf zostanie nadpisana. Prościej jest


Mam dokładnie tak jak ty masz.
Moja metoda nazywa sie

public void Button1Click(View view) {

}
I w niej to samo.co ty

W XML-u layoutu jest
android:onClick="Button1Click"
I to wszystko.
Z tym sprawdzeniem zera działa jak tego obaj oczekujemy. Wszystko gra.
Sorki ale całości ciężko by było pokazać :-) Wiesz jak jest :-)

do góry

On 02/09/2011 01:59 PM, Lelek@ wrote:

No to chyba się wyjasniło

> public void dupa() {
> byte buf[] = new byte[256];
Tutaj buf jest referencją do twojej tablicy...

> buf = FromEditText.getBytes("UTF-8");
Ale tutaj już buf jest referencją do obiektu zwróconego przez
FromEditText.getBytes(). Wskazanie do tablicy, która zaalokowałeś
zostało stracone i przydzieloną pamięcią zajmie się przy najbliższej
okazji garbage collector.
Powyższy kod jest równoważny takiej linijce:

byte buf[] = FromEditText.getBytes("UTF-8");

Ja bym twój kod przepisał do takiej postaci:

byte buf[] = FromEditText.getBytes("UTF-8");
int bfx[] = nil;
if(buf.length>0)
{
bfx[] = new int[buf.length];
for (i = 0; i < buf.length; i++)
{
//elementy buf mają po 8 bitów, więc maskowanie 0xff
//jest trochę bez sensu
bfx[i] = ((int)buf[i] & 0xFF);
}
}

if(bfx!=nil)
{
//robimy cos z bfx
}

Bardzo ważne jest alokowanie pamięci na bfx po odczytaniu zawartości
buf. Przy alokowaniu bfx o stałej długości, dopóki FromEditText.getBytes
zwróci tablicę mniej niż 256 bajtów, program będzie działał poprawnie.
Ale jeśli buf będzie dłuższe niż długość bfx, program wywali się z
błędem dostępu do pamięci przy próbie zapisu pierwszego elementu, który
się nie mieści w bfx.


BTW. próbowałeś przechwytywać wyjątki?

pzdr.
j.

do góry

"Jacek Radzikowski" <j...@s...die.die.die.piranet.org> wrote in message
news:iivdpv$o2u$1@inews.gazeta.pl...

>
> Ja bym twój kod przepisał do takiej postaci:
>
> byte buf[] = FromEditText.getBytes("UTF-8");
> int bfx[] = nil;

if(buf.length>0) <----------- on tego nie rozumie

dla niego ten buf nie istnieje. Trzeba go zadeklarować globalnie w funkcji

> //elementy buf mają po 8 bitów, więc maskowanie 0xff
> //jest trochę bez sensu
> bfx[i] = ((int)buf[i] & 0xFF);

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 :-)

do góry

On 02/09/2011 09:13 PM, Lelek@ wrote:
>
> "Jacek Radzikowski" <j...@s...die.die.die.piranet.org> wrote in
> message news:iivdpv$o2u$1@inews.gazeta.pl...
>
>>
>> Ja bym twój kod przepisał do takiej postaci:
>>
>> byte buf[] = FromEditText.getBytes("UTF-8");
>> int bfx[] = nil;
>
> if(buf.length>0) <----------- on tego nie rozumie
>
> dla niego ten buf nie istnieje. Trzeba go zadeklarować globalnie w funkcji
Zadeklaruj buf tak, żeby był widoczny wszędzie gdzie występują odwołania
do niego. Z kodu, który zacytowałeś wynikało że buf jest deklarowany na
tym samym poziomie zagłębienia co odwołanie do FromEditText.getBytes().
A ifie brakuje jeszcze jednego warunku:
if((buf != nil ) && (buf.length>0))


>> //elementy buf mają po 8 bitów, więc maskowanie 0xff
>> //jest trochę bez sensu
>> bfx[i] = ((int)buf[i] & 0xFF);
>
> 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 :)

pzdr.
j.

do góry

"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
binarnych to w kółko trzeba konwerować to co zwracają funkcje w byte signed
do signed int ale wymaskowywać je. Idiotyzm.

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 wyprawiają.
Dokładnie robia to jakby zaczynali progframować w bascomie i nie rozumieją
co czynią :-)
Z tego co się dowiedziałem to Java powstała bo ludzie nie rozumieli
wskaźników i zapominali o zwalnianiu zaalokowanych zasobów :-)

do góry

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.

do góry

"Lelek@" <n...@n...pl> wrote in message news:ij02dc$crn$1@opal.futuro.pl...
>
> "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
> binarnych to w kółko trzeba konwerować to co zwracają funkcje w byte
> signed do signed int ale wymaskowywać je. Idiotyzm.
>
> 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 wyprawiają.
> Dokładnie robia to jakby zaczynali progframować w bascomie i nie rozumieją
> co czynią :-)
> Z tego co się dowiedziałem to Java powstała bo ludzie nie rozumieli
> wskaźników i zapominali o zwalnianiu zaalokowanych zasobów :-)

Sam się śmiejesz że Java to takie C ale nie rozumiesz, że robisz
w tej Javie coś w stylu:

char data[100]="abcedefghijklmnoprstuwz";
char * buf = (char*)malloc(100);

a potem robisz coś na kształt:

buf = data;

zamiast

strcpy(buf, data);

I dziwisz się, że nie masz tam tego, co zwróciło malloc(). Pomyśl chwilkę...

do góry

Dnia 07-02-2011 o 12:39:30 Lelek@ <n...@n...pl> napisał(a):

>
> "Shaman" <s...@o...com> wrote in message news:op.vqiyljhl4limig@sioux...
> Dnia 07-02-2011 o 08:26:16 Artur M. Piwko <m...@b...pl>
>
> Już wiem co jest.
> Ten bufor nie istnieje jeżeli nic się tam nie wpisze i próba odczytu
> buf[0] bez wcześniejszego wpisania czegoś skutkuje totalną wywałką tak
> jakby wyskakiwał wyjątek nie wiadomo od czego. To jest java, a nie C++
> co mnie bardzo denerwuje, szczególnie brak "unsigned" - to jest już
> totalna porażka. Ta java to takie C++ dla półgłówków, którzy mieli
> problem ze zrozumieniem wskaźników, struktur i wykonywania kodu :-)
> Tragedia ale nie ma wyjścia.

Wszystko jest totalną porażką jeśli się nie ma odpowiedniej wiedzy :)
Jedyne do czego można się przyczepić to, że kompilator Cie nie ostrzegł
przed użyciem niezainicjowanej zmiennej. No chyba, że ostrzegł, tylko
należysz do tych co instrukcje obsługi czytają dopiero jak wszystkie inne
sposoby zawiodą :)

--
PZDR
Shaman

do góry

On Fri, 11 Feb 2011 14:01:29 +0100, Shaman wrote:
>Dnia 07-02-2011 o 12:39:30 Lelek@ <n...@n...pl> napisał(a):
>> Ta java to takie C++ dla półgłówków, którzy mieli
>> problem ze zrozumieniem wskaźników, struktur i wykonywania kodu :-)
>> Tragedia ale nie ma wyjścia.
>
>Wszystko jest totalną porażką jeśli się nie ma odpowiedniej wiedzy :)
>Jedyne do czego można się przyczepić to, że kompilator Cie nie ostrzegł
>przed użyciem niezainicjowanej zmiennej. No chyba, że ostrzegł, tylko
>należysz do tych co instrukcje obsługi czytają dopiero jak wszystkie inne
>sposoby zawiodą :)

Alez byla zainicjowana i to nawet dwa razy.

Co najwyzej Javie brakuje definicji funkcji ktora moze zwrocic NULL
zamiast referencji i ostrzegania jesli programista nie sprawdza tego
warunku przed odwolaniem :-)



J.

do góry