[d.....i]

Podobno prawdziwy slajd z którejś z rodzimych politechnik.

Ostrzegam, "trik" z iteracją po tablicy powoduje raka.

#programowanie #java i chyba trochę #humorinformatykow

[m.....y]

@dziki: Nie rozumiem. ( ͡° ʖ̯ ͡°)

[s.....a]

@dziki: bardzo fajny ten trik, ja z niego często korzystam, bo przez to nie trzeba się martwić o wielkość tablicy

[s.....a]

@dziki: czemu niby powoduje raka?

[Jurigag]

@slucham-psa-jak-gra: bo jak obsluzysz ten wyjątek? XD

[s.....a]

@Jurigag: ale po co go obsługiwać? zostawiam catch pusty

[wytrzzeszcz]

@malio_day: @slucham-psa-jak-gra: @Jurigag: nie róbcie jak w triku kurde zaoszczedzisz może 5 cykli zegara a czytelność i stabilność leci na ryj

[Jurigag]

@slucham-psa-jak-gra: dlatego właśnie powoduje raka xD

[K.....1]

@dziki: pierwszy trik jak najbardziej prawdziwy, a raczej nie trik tylko tak sie powinno robic

[3mortis]

A powie ktos jeszcze czemu iterowac do 0 ?

[maniac777]

bardzo fajny ten trik, ja z niego często korzystam,

@slucham-psa-jak-gra: a potem to z prawej strony.

pierwszy trik jak najbardziej prawdziwy, a raczej nie trik tylko tak sie powinno robic

@Kopytko1: przypuszczam ze wspolczesne kompilatory i tak w wielu wypadkach zrobia ten trik za Ciebie.

[t0fu]

@wytrzzeszcz: Nic się nie zaoszczędzi a ten trik może tylko zaszkodzić wydajności. Jak iterujesz od 0 do N to kompilator wyłącza sprawdzanie czy przekroczyliśmy zakres tablicy (ponieważ jest to niemożliwe), jak masz nieskończoną pętlę to wtedy musi to sprawdzić za każdym razem co jest dużo gorsze.

[Kuriozal]

@dziki: dobry trik. Generowanie stacktrace'a lepsze niz zakonczenie petli ( ͡° ͜ʖ ͡°)

[GotoFinal]

@wytrzzeszcz:
Pomijacie najważniejsze, tworzenie wyjątku trwa... i to bardzo długo, szczególnie jak metoda jest "głęboko", więc kod spowolni, i to mocno :D
Sam nawet gdzieś tworzyłem własne Integer.parseInt, bo potrzebowałem czegoś do szybkiego wychwytywania poprawnych intów z ciągu wyrazów, a przez te wywalane exception kod był tak wolny że nie dało się go używać.

[Eoghan]

@3mortis: teoretycznie autorowi chodziło pewnie o to, że na poziomie assembly masz możliwość albo porównywania dwóch wartości, np.:
beq $t0, $t1
ale często (zawsze?) jest też osobny operator porównania z zerem i wtedy odczytujemy tylko jeden rejestr:
beqz $t0
(choć na pewno by trzeba sprawdzić, czy na każdym procesorze tak to zadziała).
bardzo wątpliwe, że akurat w przypadku Javy da nam to zysk zauważalny choćby na poziomie milisekundy, chyba, że

[3mortis]

@Eoghan: Dzięki :) nie pomyslalem ze na niskim poziomie mozna zoptymalizowac porownanie z 0

[GotoFinal]

@Eoghan: @3mortis: Jako ciekawostkę dodam że porównywanie w javie inta do 0 lub 1 też ma osobne bytecode, i mając też pole z intem i pole z booleanem, sprawdzenie if(bool) a if (int == 1) generuje takie samo bytecode. (szczególnie że na stosie boolean i tak jest traktowany jako 32 bitowa liczbowa.)

[P.....3]

@GotoFinal: Jakim stosie?

[GotoFinal]

@Porana123: stack memory, to czego używa każda metoda itd.
int a = 5;
int b = 6;
int c = a + b;
wszystko ma tutaj 32 bity co dla każdego jest oczywiste, ale jak zmienimy wszystko na np "short", to dalej wszystko będzie miało 32 bity i instrukcje bytecode zostaną te same, co nawet widać po tym że java wywali błąd kompilacji pisząc że a + b zwraca int

[P.....3]

@GotoFinal: Po prostu każdy slot stack memory jest 32 bitowy, więc no nie ma siły żeby coś zajmowało mniej.

I nie wywali błędu xD

[Karatte]

@dziki: ale tagujcie #pwr ( ͡° ͜ʖ ͡°)