[cross] Java edukacija na TVZ-u
rai
Razmišljam da upišem Java edukaciju na TVZ-u:
http://netakademija.tvz.hr/java/nastava-i-plan/
...pa me zanimaju neke stvari, pogotovo iskustva polaznika. Da li je
to vrijedno uloženih novaca i da li su instruktori kvalitetni? Koliko
vidim, grupa koju bih pohađao pohađao poučava Marijan Matić, dipl.
ing. rač., SCJP. Profil predavača sugerira da se radi o iskusnom
programeru i predavaču, no, s obzirom da investiram vlastiti novac,
ipak me zanimaju iskustva polaznika, ali i studenata kojima Marijan
predaje.
Iako mi baš ne odgovara lokacija, TVZ-ova ponuda mi se čini
zanimljivom prije svega zato što ima umjeren ritam (2x tjedno) pa sam
stekao dojam da bih tako kvalitetnije usvojio gradivo nego da sve
odslušam za nekakvih tjedan dana.
Hvala unaprijed.
Igor Jagec
Hvala unaprijed.
--
Igor
Bruno Babic
> ...pa me zanimaju neke stvari, pogotovo iskustva polaznika. Da li je
Nisam polaznik, ali gledajuci "program" predavanja, mogu ti reci da ca
ti se prvi semestar svesti na hrpu teoretiziranja i malo konkretne
prakse. Taj dio je poprilicno nepotreban bilo kome tko vec otprije zna
programirati u nekom drugom programskom jeziku, a pogotovo ako je taj
jezik iole OO.
Drugi semestar je vec nesto konketniji, ali i dalje mislim da se sve to
moze nauciti (i besplatno) iz online tutorijala.
--
bbabic(a)globalnet.hr
2b||!2b?
Screamin Lord Byron
> Igor Jagec wrote:
>> ...pa me zanimaju neke stvari, pogotovo iskustva polaznika. Da li je
>
> Nisam polaznik, ali gledajuci "program" predavanja, mogu ti reci da ca
> ti se prvi semestar svesti na hrpu teoretiziranja i malo konkretne
> prakse.
Ja sam bio i mogu reći upravo suprotno. Prvi semestar se svodi na
drljanje po inicijalizaciji varijabli, petljama, kontroli toka u obliku
besmislenih zadataka. Uglavnom, potpuni gubitak vremena za nekoga tko
programira od prije.
Nevjerojatno mi je bilo kako 90% polaznika to ne razumije, iako su
gotovo svi izjavili da već dugo programiraju u drugim jezicima.
> Taj dio je poprilicno nepotreban bilo kome tko vec otprije zna
> programirati u nekom drugom programskom jeziku, a pogotovo ako je taj
> jezik iole OO.
Apsolutno se slažem. Da stvar bude gora, većinu prvog semestra su činile
"vježbe" koje su uključivale čisto proceduralno programiranje. Kad sam
pitao zašto se toliko koncentriramo na petlje i if/then grananja i
statičke metode, odgovor je bio da to moramo dobro utvrditi prije nego
što krenemo dalje. Razlog zašto sam dobio takav odgovor je ležao u tome
što većina grupe nije znala stvari poput osnova booleove algebre,
činjenice da while znači while a ne until, kako funkcionira for petlja i
slično.
Kad smo napokon počeli raditi OOP i ostatak programa, bio je totalni
kaos i mnogi polaznici su odustali, jer jednostavno nisu mogli pratiti.
> Drugi semestar je vec nesto konketniji,
Točno, ali gradivo drugog semestra se nije obrađivalo ni približno
detaljno kao ono s početka prvog. To se samo preletilo jer je ostalo
premalo vremena (radili su se zaostaci iz prvog semestra).
Ja sam bio u jednoj od prvih grupa. Kasnije sam razgovarao s predavačem
koji je i sam shvatio da to tako ne može funkcionirati, pa je rekao da
će predložiti da se uvede nekakav ulazni ispit.
OP-u bih predložio da se informira postoji li takav ispit i ako ne
postoji, toplo preporučam da zaobiđe ovaj tečaj.
> ali i dalje mislim da se sve to
> moze nauciti (i besplatno) iz online tutorijala.
Ako završi u grupi u kakvoj sam ja bio, ionako će to morati napraviti.
Doduše, na tečaju se dobije knjiga Core Java (Horstmann/Cornell), koja
je kvalitetna, a košta nekih 50-ak dolara. Da sam prije znao kako će
tečaj izgledati, kupio bih tu knjigu i uštedio preko 6000 kuna.
Bruno Babic
> Apsolutno se slažem. Da stvar bude gora, većinu prvog semestra su činile
> "vježbe" koje su uključivale čisto proceduralno programiranje. Kad sam
> pitao zašto se toliko koncentriramo na petlje i if/then grananja i
> statičke metode, odgovor je bio da to moramo dobro utvrditi prije nego
> što krenemo dalje. Razlog zašto sam dobio takav odgovor je ležao u tome
> što većina grupe nije znala stvari poput osnova booleove algebre,
> činjenice da while znači while a ne until, kako funkcionira for petlja i
> slično.
Ma to je standardni sadrzaj za popunjavanje vremena. Najveci problem je
sto bi taj tecaj teoretski trebao pokrivati i one koji nikada nisu
programirali kao i one koji su vec programirali u nekom drugom jeziku.
Na kraju je za ove potonje prelagan i dosadan, a za one prve pretezak. A
najbolje od svega je sto na kraju niti oni prvi niti oni drugi nemaju
pojma :)
--
bbabic(a)globalnet.hr
2b||!2b?
Screamin Lord Byron
> Screamin Lord Byron wrote:
>> Apsolutno se slažem. Da stvar bude gora, većinu prvog semestra su činile
>> "vježbe" koje su uključivale čisto proceduralno programiranje.
> Ma to je standardni sadrzaj za popunjavanje vremena.
Ne razumijem kako im se to isplati? Postoje tečajevi koji su sadržajno
identični ovom, ali s nezanemarivo manjim brojem sati (40 u odnosu na
160). Cijena je otprilike ista. Ne mislim da je povećanje broja sati u
odnosu na takve tečajeve samo marketinški trik.
Bez obzira na to što sam razočaran tečajem, svejedno mislim da je ta
"slow-pace" ideja u načelu dobra, samo bi se trebalo daleko strože
držati programa, bolje i strože organizirati vrijeme (odrediti adekvatan
broj sati za svaku temu) te organizirati sadržaj svakog predavanja,
svesti uvod u programiranje na minimum i maksimalno se posvetiti temi
tečaja (u ovom slučaju Javi). Mislim da 160 kvalitetno i smisleno
odrađenih sati u periodu od 3 ili 4 mjeseca nije previše, ali je
dovoljno da polaznik stekne čvrste temelje, ako se vrijeme iskoristi
kako treba. Naravno, u tih 160 sati nema mjesta nekakvom "popunjavanju
vremena".
> Najveci problem je
> sto bi taj tecaj teoretski trebao pokrivati i one koji nikada nisu
> programirali kao i one koji su vec programirali u nekom drugom jeziku.
Da. To je velika pogreška. Zbog toga je ideja o ulaznom ispitu dobra.
Tada se ne bi dva mjeseca obrađivale teme poput "Petlje i naredbe
kontrole toka programa u programskom jeziku Java", već bi se to samo
spomenulo u jednom ili dva sata uz kratko objašnjenje Javine sintakse i
razlika u odnosu na sintaksu iz koje je nastala.
Niti jedno poglavlje nije suvišno, ali se cijela stvar mora bolje
vremenski organizirati. Ja sam naivno mislio da je to napravljeno, ali
ispostavilo se da toga uopće nema. Uopće nije određeno koliko će se dugo
neka tema obrađivati, a tek sam kasnije primijetio da na njihovim
stranicama piše:
"Puno toga ovisi i o kvaliteti grupe studenata, ali prilagođavamo se u
dogovoru s vama svakoj situaciji"
To je IMHO jedna velika glupost koju oni očito vide kao nešto pozitivno.
To "prilagođavanje" nikome ne koristi, jer se radi o grupnom, a ne
individualnom tečaju. Tu, kao što si rekao, nastradaju svi. Oni koji
razumiju imaju osjećaj dosade i gubljenja vremena, a oni drugi
naposlijetku odluče odustati. Na kraju za složenije teme jednostavno ne
ostane dovoljno vremena. Lose-lose.
rai
>> ...pa me zanimaju neke stvari, pogotovo iskustva polaznika. Da li je
>Nisam polaznik, ali gledajuci "program" predavanja, mogu ti reci da ca
>ti se prvi semestar svesti na hrpu teoretiziranja i malo konkretne
>prakse. Taj dio je poprilicno nepotreban bilo kome tko vec otprije zna
>programirati u nekom drugom programskom jeziku, a pogotovo ako je taj
>jezik iole OO.
Znači da bi meni dobro došao :)
Nije da ne znam baš ništa o programiranju, ali dobro bi mi došlo da se
krene od samih početaka pa da to sjedne malo bolje...
>Drugi semestar je vec nesto konketniji, ali i dalje mislim da se sve to
>moze nauciti (i besplatno) iz online tutorijala.
U samim početcima nije loše krenuti kroz neki program edukacije pa da
steknem temelje za samostalan rad.
rai
>On 03.08.2010 11:47, Bruno Babic wrote:
>>> ...pa me zanimaju neke stvari, pogotovo iskustva polaznika. Da li je
>> Nisam polaznik, ali gledajuci "program" predavanja, mogu ti reci da ca
>> ti se prvi semestar svesti na hrpu teoretiziranja i malo konkretne
>> prakse.
>Ja sam bio i mogu reći upravo suprotno. Prvi semestar se svodi na
>drljanje po inicijalizaciji varijabli, petljama, kontroli toka u obliku
>besmislenih zadataka. Uglavnom, potpuni gubitak vremena za nekoga tko
>programira od prije.
Meni bi u tom slučaju bilo zgodno da se prođe kroz to.
>Nevjerojatno mi je bilo kako 90% polaznika to ne razumije, iako su
>gotovo svi izjavili da već dugo programiraju u drugim jezicima.
Znači da ljudi lažu, što nije ništa neuobičajeno. Što se mojeg
iskustva tiče, imam gadan hendikep što na faksu nisam učio
programiranje, ali zato na poslu pišem Bash i Korn shell skripte za
Linux i AIX (a to su isto programski jezici, bez obzira što nisu neki
high level) pa ponešto znam od gore navedenih osnova. Nije da pišem
high level skripte, ali trebalo mi je dosta vremena i energije da sve
i to dobro uvježbam. Jedna je stvar kad čovjek zna pročitati kôd, kad
razumije kad mu netko nešto objašnjava od tog gradiva, ali sasvim je
nešto drugo kad treba konkretno nešto napraviti iz nule, a tada i low
level skripte mogu biti problem za napisati.
>> Taj dio je poprilicno nepotreban bilo kome tko vec otprije zna
>> programirati u nekom drugom programskom jeziku, a pogotovo ako je taj
>> jezik iole OO.
>Apsolutno se slažem. Da stvar bude gora, većinu prvog semestra su činile
>"vježbe" koje su uključivale čisto proceduralno programiranje. Kad sam
>pitao zašto se toliko koncentriramo na petlje i if/then grananja i
>statičke metode, odgovor je bio da to moramo dobro utvrditi prije nego
>što krenemo dalje. Razlog zašto sam dobio takav odgovor je ležao u tome
>što većina grupe nije znala stvari poput osnova booleove algebre,
>činjenice da while znači while a ne until, kako funkcionira for petlja i
>slično.
Ajde ipak nešto od toga znam, ali svejedno nije loše to dobro
izvježbati prije no što se krene dalje. Međutim, jako je loše ako se
težište edukacije svede na to a ne na neke druge važnije stvari. Takve
stvari bi se po meni trebale predavati u nekom razumnom broju sati i
dobro to izvježbati kod kuće.
>Kad smo napokon počeli raditi OOP i ostatak programa, bio je totalni
>kaos i mnogi polaznici su odustali, jer jednostavno nisu mogli pratiti.
Lijepo je kad ljudi odustanu na vrijeme pa da broj polaznika bude što
manji, ali loše je ako ti polaznici u međuvremenu naruše ritam
predavanja i sve to.
>> Drugi semestar je vec nesto konketniji,
>Točno, ali gradivo drugog semestra se nije obrađivalo ni približno
>detaljno kao ono s početka prvog. To se samo preletilo jer je ostalo
>premalo vremena (radili su se zaostaci iz prvog semestra).
Da, to baš i nije dobro... Ali valjda su sad nešto naučili iz iskustva
pa da sad to ide malo bolje.
>Ja sam bio u jednoj od prvih grupa. Kasnije sam razgovarao s predavačem
>koji je i sam shvatio da to tako ne može funkcionirati, pa je rekao da
>će predložiti da se uvede nekakav ulazni ispit.
Nego, kakva je po tebi kvaliteta predavača? Meni se profil predavača
čini oke, ali svejedno mi je lijepo čuti iskustva iz prve ruke. Hvala.
>OP-u bih predložio da se informira postoji li takav ispit i ako ne
>postoji, toplo preporučam da zaobiđe ovaj tečaj.
Uh... da, dobro veliš... ipak nije baš jeftin, a i jako mi je gadno
zbog putovanja u ZG gdje radim, pa i bez toga gubim puno vremena na
putovanje.
>> ali i dalje mislim da se sve to
>> moze nauciti (i besplatno) iz online tutorijala.
>Ako završi u grupi u kakvoj sam ja bio, ionako će to morati napraviti.
>Doduše, na tečaju se dobije knjiga Core Java (Horstmann/Cornell), koja
>je kvalitetna, a košta nekih 50-ak dolara. Da sam prije znao kako će
>tečaj izgledati, kupio bih tu knjigu i uštedio preko 6000 kuna.
Ja doma imam od Suna Java Tutorial. Ova gore navedena je baš
namjenjena tečaju i prati program?
rai
>On 03.08.2010 19:04, Bruno Babic wrote:
>> Ma to je standardni sadrzaj za popunjavanje vremena.
>Ne razumijem kako im se to isplati? Postoje tečajevi koji su sadržajno
>identični ovom, ali s nezanemarivo manjim brojem sati (40 u odnosu na
>160). Cijena je otprilike ista. Ne mislim da je povećanje broja sati u
>odnosu na takve tečajeve samo marketinški trik.
Ja sam baš razmišljao o ovoj varijanti zbog većeg broja sati pa da
bolje izvježbam te osnove i sve ostalo. A i ritam od 2 puta tjedno mi
se čini ok, za razliku od nekakvog intenzivnog gdje će se sve nabrzinu
ispredavati pa jednako brzo ispariti iz glave.
>> Najveci problem je
>> sto bi taj tecaj teoretski trebao pokrivati i one koji nikada nisu
>> programirali kao i one koji su vec programirali u nekom drugom jeziku.
>Da. To je velika pogreška. Zbog toga je ideja o ulaznom ispitu dobra.
>Tada se ne bi dva mjeseca obrađivale teme poput "Petlje i naredbe
>kontrole toka programa u programskom jeziku Java", već bi se to samo
>spomenulo u jednom ili dva sata uz kratko objašnjenje Javine sintakse i
>razlika u odnosu na sintaksu iz koje je nastala.
Uh... pa to je skoro pola edukacije?!? Hm...
>Niti jedno poglavlje nije suvišno, ali se cijela stvar mora bolje
>vremenski organizirati. Ja sam naivno mislio da je to napravljeno, ali
>ispostavilo se da toga uopće nema. Uopće nije određeno koliko će se dugo
>neka tema obrađivati, a tek sam kasnije primijetio da na njihovim
>stranicama piše:
>"Puno toga ovisi i o kvaliteti grupe studenata, ali prilagođavamo se u
>dogovoru s vama svakoj situaciji"
Ha čuj, žele se ograditi za slučaj eventualnih sudskih tužbi :)
>To je IMHO jedna velika glupost koju oni očito vide kao nešto pozitivno.
>To "prilagođavanje" nikome ne koristi, jer se radi o grupnom, a ne
>individualnom tečaju. Tu, kao što si rekao, nastradaju svi. Oni koji
>razumiju imaju osjećaj dosade i gubljenja vremena, a oni drugi
>naposlijetku odluče odustati. Na kraju za složenije teme jednostavno ne
>ostane dovoljno vremena. Lose-lose.
Hm... obojica ste mi dali povoda za razmišljanje, puno hvala.
Nego, da samo spomenem zašto uopće planiram upisati tu edukaciju.
Radim na poslu kao sistemaš, a glavni posao mi je administracija
IBM-ovog Websphere Application Servera (WAS-a). Dobro radim posao,
snalazim se u svemu tome, ali osjećam da mi je veliki nedostatak
znanja iz Java programiranja te da bih puno bolje radio posao da
naučim nešto o Javi. Naime, najvažniji WAS logovi su mi JVM logovi. A
mislim da bih puno brže i kvalitetnije čitao JVM logove da naučim
nešto o Javi, a i usput bih si malo popravio reference te proširio
mogućnosti ukoliko mi se jednog dana pruži prilika za nekakvo
napredovanje ili sl.
Screamin Lord Byron
> [Default] Screamin Lord Byron <sc...@min.dot> ha scritto:
>> gotovo svi izjavili da već dugo programiraju u drugim jezicima.
>
> Znači da ljudi lažu, što nije ništa neuobičajeno.
Nije, ali iza laganja uvijek leži neki razlog, osim ako nisi patološki
lažljivac. Razlog zašto lagati o iskustvu s nekim programskim jezikom na
tečaju za programski jezik je izvan moje moći shvaćanja.
> Što se mojeg
> iskustva tiče, imam gadan hendikep što na faksu nisam učio
> programiranje, ali zato na poslu pišem Bash i Korn shell skripte za
> Linux i AIX (a to su isto programski jezici, bez obzira što nisu neki
> high level) pa ponešto znam od gore navedenih osnova.
Nisam siguran da razumijem što podrazumijevaš pod to da nisu high level.
Shell skripte su high level po definiciji.
> Ajde ipak nešto od toga znam, ali svejedno nije loše to dobro
> izvježbati prije no što se krene dalje. Međutim, jako je loše ako se
> težište edukacije svede na to a ne na neke druge važnije stvari. Takve
> stvari bi se po meni trebale predavati u nekom razumnom broju sati i
> dobro to izvježbati kod kuće.
A gle, kad se prvi put susrećeš s programiranjem, onda je to valjda
teško i nerazumljivo, ali ako si prije pisao bilo kakav kod, sve što
trebaš je naučiti novu sintaksu, a za to ti ne treba više od jednog
popodneva.
To vrijedi za općenite stvari. Naravno da Java, kao i svaki jezik, ima
svoje specifičnosti za koje ti treba malo više. Osim toga, tu su još
dijelovi libraryja koje moraš znati na pamet ako želiš efikasno
programirati (nećeš za svaku metodu i klasu stalno roštati po
dokumentaciji). To su stvari kojima se tečaj trebao daleko više posvetiti.
> Nego, kakva je po tebi kvaliteta predavača? Meni se profil predavača
> čini oke, ali svejedno mi je lijepo čuti iskustva iz prve ruke. Hvala.
Bez sumnje, predavač je stručnjak za programiranje. Međutim, na mene
nije ostavio dojam dobrog predavača. Dijelom zbog toga što nije imao
pisanu pripremu za svaki sat, pa se događalo da neke važne stvari
zaboravi spomenuti, a dijelom zbog samog stila predavanja koji meni nije
odgovarao, s čestim nepotrebnim digresijama. To ne znači da neće
odgovarati nekom drugom. Evo, jedan od kolega s tečaja mi je rekao da
baš odlično predaje. Doduše, taj kolega je bio jedan od onih koji su
odustali. :)
Ja se uvijek pitam zašto nešto radi tako kako radi, jer na taj način
bolje shvaćam i ne moram pamtiti redundantne stvari. S druge strane,
nekome je jednostavnije učiti napamet. Njegov stil predavanja je bio
bliži zadnjima (pogotovo kad se došlo do generičkog programiranja), a
ponekad i s nekim (meni) mutnim objašnjenjima.
Npr.:
- u Javi se parametri prosljeđuju by value, ali za objekte to možete
gledati i kao by reference.
Ja pitam
- u kom smislu možemo tako gledati?
- Tako što prosljeđujete referencu na objekt.
- Hmm. A nismo li zapravo by value proslijedili kopiju reference?
- Pa da, ali nećemo sad zbunjivati ljude.
WTF? Meni je zbunjujuće ako dobijem poluinformaciju koja u suštini nije
ni točna. Nije isto proslijediti nešto by reference ili kopiju reference
(na objekt) by value. To u nekim slučajevima može izgledati kao ista
stvar, ali prije ili kasnije ćeš se opeći ako misliš da je isto.
> Ja doma imam od Suna Java Tutorial. Ova gore navedena je baš
> namjenjena tečaju i prati program?
Ova je isto od Suna (Sun Microsystems Press). Tečaj se otprilike vodi
knjigom (osim što na tečaju nema Reflectiona), ali ne kronološki. Iz
nekog meni nepoznatog razloga su odlučili ispremiješati neke cjeline.
Prođe se još kroz File IO i mrežu, što je u drugoj knjizi (Core Java,
Volume II -- nju ne dobiješ na tečaju).
Screamin Lord Byron
> Nego, da samo spomenem zašto uopće planiram upisati tu edukaciju.
> Radim na poslu kao sistemaš, a glavni posao mi je administracija
> IBM-ovog Websphere Application Servera (WAS-a). Dobro radim posao,
> snalazim se u svemu tome, ali osjećam da mi je veliki nedostatak
> znanja iz Java programiranja te da bih puno bolje radio posao da
> naučim nešto o Javi. Naime, najvažniji WAS logovi su mi JVM logovi. A
> mislim da bih puno brže i kvalitetnije čitao JVM logove da naučim
> nešto o Javi, a i usput bih si malo popravio reference te proširio
> mogućnosti ukoliko mi se jednog dana pruži prilika za nekakvo
> napredovanje ili sl.
Na ovom tečaju nećeš naučiti ništa o JVM-u.
Smola
says...
> Nego, da samo spomenem zašto uopće planiram upisati tu edukaciju.
> Radim na poslu kao sistemaš, a glavni posao mi je administracija
> IBM-ovog Websphere Application Servera (WAS-a). Dobro radim posao,
> snalazim se u svemu tome, ali osjećam da mi je veliki nedostatak
> znanja iz Java programiranja te da bih puno bolje radio posao da
> naučim nešto o Javi. Naime, najvažniji WAS logovi su mi JVM logovi. A
> mislim da bih puno brže i kvalitetnije čitao JVM logove da naučim
> nešto o Javi, a i usput bih si malo popravio reference te proširio
> mogućnosti ukoliko mi se jednog dana pruži prilika za nekakvo
> napredovanje ili sl.
Sistemasima mozda vise treba znanje arhitekture apliakcije odn. app-
sererva, ali mislim da si pogodio jer od neceg trebas poceti. Na stranu
kvaliteta tecaja.
--
ako u kavi ostanu grumeni, promijesajte ponovo
Smola
> Npr.:
> - u Javi se parametri prosljeđuju by value, ali za objekte to možete
> gledati i kao by reference.
> Ja pitam
> - u kom smislu možemo tako gledati?
> - Tako što prosljeđujete referencu na objekt.
> - Hmm. A nismo li zapravo by value proslijedili kopiju reference?
> - Pa da, ali nećemo sad zbunjivati ljude.
>
> WTF? Meni je zbunjujuće ako dobijem poluinformaciju koja u suštini nije
> ni točna. Nije isto proslijediti nešto by reference ili kopiju reference
> (na objekt) by value. To u nekim slučajevima može izgledati kao ista
> stvar, ali prije ili kasnije ćeš se opeći ako misliš da je isto.
Ja u javi nikad nisam trebao znati kako se sto proslijedjuje, a kamoli
da sam se opekao zbog toga. :)
Zeljko Vrba
>
> Ja sam baš razmišljao o ovoj varijanti zbog većeg broja sati pa da
> bolje izvježbam te osnove i sve ostalo. A i ritam od 2 puta tjedno mi
> se čini ok, za razliku od nekakvog intenzivnog gdje će se sve nabrzinu
> ispredavati pa jednako brzo ispariti iz glave.
>
u nekom vremenskom razdoblju je ogranicena.
>>Da. To je velika pogreška. Zbog toga je ideja o ulaznom ispitu dobra.
>>Tada se ne bi dva mjeseca obrađivale teme poput "Petlje i naredbe
>>kontrole toka programa u programskom jeziku Java", već bi se to samo
>>spomenulo u jednom ili dva sata uz kratko objašnjenje Javine sintakse i
>>razlika u odnosu na sintaksu iz koje je nastala.
>
> Uh... pa to je skoro pola edukacije?!? Hm...
>
75% edukacije je nauciti algoritamski razmisljati. Sintaksa je gotovo pa
trivijalna, moze se nauciti CITATI proceduralni java kod za jedan dan. Prvi
korak za naucit algoritamski razmisljati je, IMHO, nauciti DOSLOVNO izvrsavati
instrukcije kako su napisane u programu. Znaci, nadji kratak program, i NA
PAPIRU napisi vrijednosti svih varijabli nakon izvrsenja svake naredbe. Onda
izvrsi program i usporedi rezultate. Ako je tocno -- super, probaj izmijeniti
ulazne parametre pa ponovno[*]. Ako je tvoj simulirani rezultat pogresan --
izvrsi program u DEBUGGERU sa single-steppingom i promatraj sto se dogadja.
Kad pises program, postupak je obrnut. Krenes od zeljenog rezultata i
rasclanis ga na osnovne korake koje vode do rezultata.
[*] Dobri, ne-trivijalni primjeri su najveci zajednicki djelitelj, binarno
trazenje u arrayu, sumiranje N brojeva u arrayu, te sumiranje brojeva sve dok
korisnik ne unese neki broj. Kad ti to sjedne, mozes se malo pozabaviti
rekurzijom, npr. Fibonacci ili tornjevi Hanoja. Stringovi su samo arrayevi
brojeva i mislim da se u pocetku ne trebas zamarati s njima dok ti ne "klikne"
kako se program izvrsava. (Put od arraya brojeva do prikaza slova na ekranu
je dugacak i mogao bih napisati jos jedan post ove duljine samo o tome.)
Sve ostalo -- eventi, threadovi, GUI, mreza, OO, itd. -- pociva na tom
osnovnom principu -- da si mozes tocno formirati ideju o sekvenci akcija koje
moras napraviti da se skup entiteta transformira iz stanja A u stanje B.
Ovdje je "entitet" bilo kakav podatak u memoriji programa, na disku, u putu
preko mreze, u tablici u nekoj bazi podataka, itd.
Osnovni objekti s kojima CPU barata su INSTRUKCIJA, BROJ i MEMORIJSKA ADRESA.
Svi ostali pojmovi su apstrakcije za ljude koje nekad pomazu, nekad odmazu.
Kad shvatis kako kompjuter barata tim objektima, razumijevanje ostalih
apstrakcija (klase, stringovi, fajlovi, itd.) je relativno straightforward.
[OT: Posto je topic Java, zadrzavam se na imperativnom programiranju.
Funkcionalni programi pocivaju na lambda-racunu gdje je osnovna apstrakcija
funkcija. Svejedno, i funkcionalni programi se na kraju svode na instrukcije,
brojeve i adrese.]
Kad napises dovoljno programa, primijetit ces da cesto pises isti ili slican
kod puno puta. Da si ustedis trud i vrijeme, sekvence programskih naredbi se
mogu enkapsulirati u funkcije. Napisi jednom, koristi bilo kada i bilo gdje.
Funkcija/procedura je skup identicnih naredbi koje obradjuju razlicite podatke
(parametri funkcije). Prednost koristenja funkcija je 1) dozvoljavaju ti
definiranje vlastitih "naredbi" [one su jednostavan nacin za prosiriti
vokabular koji ti je raspoloziv prilikom pisanja programa], 2) smanjenje
objektnog koda (bitno kod danasnjih CPU-a da ne potrosis puno instruction
cachea), 3) ako imas bug u funkciji, ispravljas ga na samo jednom mjestu. Ako
copy-pasteas neki kod na 10 mjesta u programu i otkrijes bug, moras ga
ispravljati na 10 mjesta umjesto na jednom.
Jednom kad si naucio algoritamski razmisljati (usvojio pojmove instrukcije,
broja i adrese), iduci korak je upravljanje resursima (memorija, prostor na
disku, otvoreni fajlovi, konekcije prema bazi podataka, broj threadova, itd.)
Najjednostavnija analogija upravljanja resursima je hotel: management hotela
se brine o iznajmljivanju soba, naplati, znaju koje je velicine koja soba i tko
ju koristi i evt. kada ce otici. Kad to ne bi znali, brzo bi ispali iz
biznisa. Slicno je i sa programima, ali, nazalost, lose napisani programi
prezivljavaju jer danasnji kompjuteri imaju puno resursa pa toleriraju programe
koje napisu slampavi programeri. (Java programi su notorni po ekstremnoj
potrosnji resursa.)
Iduci, i najtezi korak je upravljanje greskama -- npr. podaci koje saljes preko
mreze mogu "ispariti", baza podataka moze crknut, fajl koji treba programu je
ili izbrisan ili se desila greska na disku, nedostatak resursa, itd. U nekim
slucajevima je prihvatljivo zavrsit program uz odgovarajucu poruku (posebno
kada se ucis), u nekim slucajevima se moze malo sacekati i probati ponovno, a
ponekad uopce nije jasno kako bi se najbolje greska mogla hendlati. Exceptioni
su samo mehanizam dojavljivanja greski, a kako ces ju obraditi -- tu nimalo ne
pomazu.
To su otprilike najbitniji principi programiranja. Ne znam ima li sto teze od
rukovanja greskama. [Neki bi mozda rekli paralelno/distribuirano programiranje,
ali i tamo je opet rukovanje greskama stalna tema -- posebno u distribuiranim
sistemima gdje bilo koji resurs moze bilo kada nestati.] Mozda odrzavanje --
dodavanje nove funkcionalnosti, pogotovo koja nije u startu planirana, bez da
se potrga postojeca funkcionalnost.
A kad program postane dovoljno velik, tu uskacu design patterns, objekti,
inheritance, bla, buzzword, crap. To su samo sredstva koja, ISPRAVNO
UPOTRIJEBLJENA, smanjuju kolicinu informacija koje moras drzati u kratkotrajnoj
memoriji (VRLO ogranicen kapacitet!) dok razvijas novi kod i pomazu da se
program lakse prosiri novom funkcionalnoscu. IMHO, "moderne novotarije" su
jako razvikane i cesto djeluju suprotno od toga kako je zamisljeno.
>
> Nego, da samo spomenem zašto uopće planiram upisati tu edukaciju.
> Radim na poslu kao sistemaš, a glavni posao mi je administracija
> IBM-ovog Websphere Application Servera (WAS-a). Dobro radim posao,
> snalazim se u svemu tome, ali osjećam da mi je veliki nedostatak
> znanja iz Java programiranja te da bih puno bolje radio posao da
> naučim nešto o Javi. Naime, najvažniji WAS logovi su mi JVM logovi. A
> mislim da bih puno brže i kvalitetnije čitao JVM logove da naučim
> nešto o Javi, a i usput bih si malo popravio reference te proširio
> mogućnosti ukoliko mi se jednog dana pruži prilika za nekakvo
> napredovanje ili sl.
>
Hm, u ovoj situaciji je IMHO, _jedina_ korist koju ces imati od tecaja da ces
vjerojatno imati vise motivacije da redovito i konstantno radis. Ako se mozes
sam motivirati da svaki dan po sat vremena citas knjigu, svaki drugi dan radis
vjezbe jednako dugo kao sto bi radio i na predavanjima -- ne bacaj lovu na
tecaj.
Bruno Babic
> Ja u javi nikad nisam trebao znati kako se sto proslijedjuje, a kamoli
> da sam se opekao zbog toga. :)
Nisam niti ja sve dok nisam dosao u situaciju da zelim promijeniti
vrijednost stringa koji je parametar metodi u kojoj ga mijenjam :)
--
bbabic(a)globalnet.hr
2b||!2b?
Bruno Babic
> U samim početcima nije loše krenuti kroz neki program edukacije pa da
> steknem temelje za samostalan rad.
Evo ti moj savjet, pa ako se ispostavi da sam pomogao, mozes mi se
zahvaliti npr. cevapima :)
Dakle, ne kosta te puno da skines Javu (java.sun.com) i Eclipse
(www.eclipse.org) i instaliras oboje.
Nakon toga, odes na Google (www.google.com) i upises "java tutorial" i
kliknes na (trenutno) drugi link
(http://www.java2s.com/Tutorial/Java/CatalogJava.htm), pa onda krenes
polako od prvog linka, pa nadalje.
Takodjer, nije lose da nabavis neku knjigu o Javi (ima ih hrpa), a mozes
i na HR jeziku ako se ne snalazis sa Engleskim, pa krenes po knjizi isto
kao i po gornjem linku.
Provedi tjedan-dva uz knjigu/tutorijal i vidi da li ti to ide ili ne
ide. Ako ne ide, onda upisi tecaj i to je to.
--
bbabic(a)globalnet.hr
2b||!2b?
Screamin Lord Byron
> Ja u javi nikad nisam trebao znati kako se sto proslijedjuje, a kamoli
> da sam se opekao zbog toga. :)
Heh, nije bitno znaš li kako se to zove ili ne, ali vjerujem da ti je
jasno zašto ne možeš napraviti sa Stringom ono što Bruno kaže ili zašto
ne možeš upotrijebiti metodu kako bi zamijenio reference dvjema varijablama.
npr (Java 5 i iznad):
...
Integer a = 1;
Integer b = 2;
swap(a, b);
// a.intValue je još uvijek 1
// b.intValue je još uvijek 2
...
void swap(Integer a, Integer b) {
Integer temp = a;
a = b;
b = temp;
}
....
a i b su reference na Integer objekte. Da se stvar prosljeđuje by
reference, ova swap() metoda bi zamijenila reference. Očito je da se ne
prosljeđuje originalna referenca, već samo vrijednost njene kopije.
U C-u (koji je isto by value) možeš "varati" s pointerima, ali Java nema
pointera pa to ne ide. U C++ možeš i bez "varanja".
Smola
>
> Smola wrote:
> > Ja u javi nikad nisam trebao znati kako se sto proslijedjuje, a kamoli
> > da sam se opekao zbog toga. :)
>
> Nisam niti ja sve dok nisam dosao u situaciju da zelim promijeniti
> vrijednost stringa koji je parametar metodi u kojoj ga mijenjam :)
Pa nisi se opekao, samo si shvatio da se to u Javi ne moze.
Smola
>
> On 05.08.2010 00:36, Smola wrote:
> > Ja u javi nikad nisam trebao znati kako se sto proslijedjuje, a kamoli
> > da sam se opekao zbog toga. :)
>
> Heh, nije bitno znaš li kako se to zove ili ne, ali vjerujem da ti je
> jasno zašto ne možeš napraviti sa Stringom ono što Bruno kaže ili zašto
> ne možeš upotrijebiti metodu kako bi zamijenio reference dvjema varijablama.
Ma to mi nikad nije ni trebalo. Opcenito, mijenjati ulazni parametar je
los dizajn.
> npr (Java 5 i iznad):
> ...
> Integer a = 1;
> Integer b = 2;
> swap(a, b);
> // a.intValue je još uvijek 1
> // b.intValue je još uvijek 2
> ...
> void swap(Integer a, Integer b) {
> Integer temp = a;
> a = b;
> b = temp;
> }
> ....
>
> a i b su reference na Integer objekte. Da se stvar prosljeđuje by
> reference, ova swap() metoda bi zamijenila reference. Očito je da se ne
> prosljeđuje originalna referenca, već samo vrijednost njene kopije.
Hm, pod originalna referenca vjerojatno mislis na referencu na tu
referencu, tj. pokazivac na referencu? :)
Zasto bi ocekivao da ces dobiti pokazivac na referencu? Zato sto je
receno da u Javi objekti idu "by reference"? Ono sto ljudi ne objasne
dobro je da zapravo sve ide "by value", a izraz "by reference" zapravo
znaci da se referenca prosljedjuje "by value", odn. da na stacku stoji
kopija reference. ;)
I nigdje neces dobiti pokazivac, osim ako to eksplicitno zatrazis ili
pretvorbom parametra u pokazivac ili kljucnom rijeci (var, ref, out...).
mimix
>
> Ma to mi nikad nije ni trebalo. Opcenito, mijenjati ulazni parametar je
> los dizajn.
Da je tako onda bi se objekti u javi slali po const referencama. Ali
čekaj, pa java niti nema "const".
>
> I nigdje neces dobiti pokazivac, osim ako to eksplicitno zatrazis ili
> pretvorbom parametra u pokazivac ili kljucnom rijeci (var, ref, out...).
Kakve ključne riječi? (Nov sam u javi)
--
Milan Mimica
http://sparklet.sf.net
Screamin Lord Byron
> Hm, pod originalna referenca vjerojatno mislis na referencu na tu
> referencu, tj. pokazivac na referencu? :)
Na brzinu sam pisao pa sam se nespretno izrazio. Mislio sam na referencu
varijable. Na stacku je, naravno, kopija vrijednosti (referenca na
objekt), a ne vrijednost kopije.
Pusti sad pointere. Pointer nije isto što i referenca.
> Zasto bi ocekivao da ces dobiti pokazivac na referencu? Zato sto je
> receno da u Javi objekti idu "by reference"?
Zato što se zna što znači pass by reference i što znači referenca na objekt.
> Ono sto ljudi ne objasne
> dobro je da zapravo sve ide "by value", a izraz "by reference" zapravo
> znaci da se referenca prosljedjuje "by value", odn. da na stacku stoji
> kopija reference. ;)
To je točno ako ne radiš razliku između reference i pointera. Tvoje
objašnjenje nije korisno, jer "pass by reference" podrazumijeva
implicitnu referencu, a ne pointer.
Prouči razliku između ova dva primjera:
----------------------------------
void foo(int* x) {
++(*x);
}
...
int x = 5;
foo(&x);
...
----------------------------------
----------------------------------
void foo(int& x) {
++x;
}
...
int x = 5;
foo(x);
...
----------------------------------
Rezultat je isti (x postane 6 kad se ovo odvrti), samo što je jedno
"pass by value", a drugo "pass by reference", po definiciji.
U Javi (iako je pass by value) ne možeš prvo jer nemaš pointera. Ne
možeš ni drugo jer nemaš "pass by reference".
> I nigdje neces dobiti pokazivac, osim ako to eksplicitno zatrazis ili
> pretvorbom parametra u pokazivac ili kljucnom rijeci (var, ref, out...).
Nema tu osim. Nigdje i nikad u Javi nećeš dobiti pointer. Ne znam što je
ovo u zagradi. C#?
mimix
>
> Ne možeš ni drugo jer nemaš "pass by reference".
Ima, ali samo za objekte. Intrizični tipovi idu po "by value". Prilično
je jednostavno i logično.
Screamin Lord Byron
> On 2010-08-05, Screamin Lord Byron wrote:
>>
>> Ne možeš ni drugo jer nemaš "pass by reference".
>
> Ima, ali samo za objekte. Intrizični tipovi idu po "by value". Prilično
> je jednostavno i logično.
Eto ga na. Nema. :)
Evo probaj. Uzmi neku immutable klasu, npr. Integer.
Integer i = 0;
++i;
Super, i je 1. Autoboxing/unboxing se podrazumijeva (Java 5 i dalje).
Ajmo sad probati napraviti isto putem metode. Mora raditi, kad kažeš da
objekti idu by reference.
public class ByReference {
public static void main(String[] args) {
Integer i = 0;
increment(i);
System.out.println(i);
}
public static void increment(Integer x) {
++x;
}
}
Hmm. Ispisuje 0. Kako sad to, kad se objekti prosljeđuju by reference?
Sva djeca (ili nasljednici) klase Number, pa tako i Integer su
immutable. To znači da im ne možeš mijenjati stanje, što znači da ako
napraviš ++x, varijabla x više neće sadržavati istu referencu, već
referencu novog objekta klase Integer.
E sad, da je Java pass by reference za objekte kao što kažeš, tada bi se
opisana promjena ulaznog argumenta x odrazila na i. No to se ne događa.
Ne događa se zato što je Java isključivo *PASS BY VALUE*. To ne znači da
se cijeli objekt na neki način šalje by value, već se by value šalje
vrijednost varijable (koja je u slučaju objekta referenca na taj objekt).
Slična je stvar i u C-u. Kad prosljeđuješ array funkciji, ne
prosljeđuješ cijeli sadržaj arraya, nego pointer na prvi element. Ali to
je i dalje *pass by value*.
Smola
>
> On 05.08.2010 17:15, Smola wrote:
>
> > Hm, pod originalna referenca vjerojatno mislis na referencu na tu
> > referencu, tj. pokazivac na referencu? :)
>
> Na brzinu sam pisao pa sam se nespretno izrazio. Mislio sam na referencu
> varijable. Na stacku je, naravno, kopija vrijednosti (referenca na
> objekt), a ne vrijednost kopije.
>
> Pusti sad pointere. Pointer nije isto što i referenca.
Uf. Meni je referenca adresa, a pointer je varijabla koja sadrzi tu
adresu, ok?
Prema tome, pointer koji sadrzi adresu pointera zapravo sadrzi referencu
na referencu.
Ili drugim rijecima, pointer na pointer je memorijska adresa koja sadrzi
adresu adrese? Ok? :)
> > Ono sto ljudi ne objasne
> > dobro je da zapravo sve ide "by value", a izraz "by reference" zapravo
> > znaci da se referenca prosljedjuje "by value", odn. da na stacku stoji
> > kopija reference. ;)
>
> To je točno ako ne radiš razliku između reference i pointera. Tvoje
> objašnjenje nije korisno, jer "pass by reference" podrazumijeva
> implicitnu referencu, a ne pointer.
Pricam o Javi di taj izraz nije isti kao u C++, dakle na stacku ne stoji
adresa reference (pointer), nego kopija reference (implicitna). Zato je
meni to isto sto i "by value". Primjer za Javu:
int x = 5;
Object obj = new Object();
Recimo da se varijabla obj nalazi na memorijskoj lokaciji 20, a da
sadrzi adresu objekta 100.
void f(int x, Object obj) {...}
Kod poziva metode na stacku ce se nalaziti:
5 - vrijednost varijeble x
100 - vrijednost varijable obj
Zato ja kazem da je sve to "by value", jer u Javi nikada nece na stacku
biti adresa varijable (20) kao sto bi bilo u tvojim primjerima ispod.
> Prouči razliku između ova dva primjera:
>
> ----------------------------------
> void foo(int* x) {
> ++(*x);
> }
> ...
> int x = 5;
> foo(&x);
> ...
> ----------------------------------
> ----------------------------------
> void foo(int& x) {
> ++x;
> }
> ...
> int x = 5;
> foo(x);
> ...
> ----------------------------------
>
> Rezultat je isti (x postane 6 kad se ovo odvrti), samo što je jedno
> "pass by value", a drugo "pass by reference", po definiciji.
[x] = 20 // adresa memorijske lokacije x je 20
x = 5 // na lokaciji 20 pise vrijednost 5
U oba tvoja slucaju se na stack stavlja ne 5, vec adresa od x, a to je
20.
Terminologija koja nalaze da se drugi primjer zove "by reference" u Javi
nema bas smisla, zar ne?
U ostalim jezicima su uvedene kljucne rijeci za prosljedjivanje
reference na varijablu (adrese varijable): u Pacalu "var", u VB-u je
"ref", a u C# je "out".
Smola
milan|tocka|mim...@globalnet.hr says...
>
> On 2010-08-05, Smola wrote:
> >
> > Ma to mi nikad nije ni trebalo. Opcenito, mijenjati ulazni parametar je
> > los dizajn.
>
> Da je tako onda bi se objekti u javi slali po const referencama. Ali
> čekaj, pa java niti nema "const".
Umjesto const mozes koristiti final u deklaraciji parametra.
Smola
> ...zato što je Java isključivo *PASS BY VALUE*. To ne znači da
> se cijeli objekt na neki način šalje by value, već se by value šalje
> vrijednost varijable (koja je u slučaju objekta referenca na taj objekt).
Eh, pa o tome pricam. :)
Screamin Lord Byron
>> Pusti sad pointere. Pointer nije isto što i referenca.
>
> Uf. Meni je referenca adresa, a pointer je varijabla koja sadrzi tu
> adresu, ok?
Možda tebi. Pointer nije (svaka) varijabla koja sadrži referencu. Riječ
pointer ili pokazivač se odnosi na specijalni tip podatka. Java nema
pointere, iako bi po tvome bilo da je varijabla reference zapravo pointer.
>>> Ono sto ljudi ne objasne
>>> dobro je da zapravo sve ide "by value", a izraz "by reference" zapravo
>>> znaci da se referenca prosljedjuje "by value", odn. da na stacku stoji
>>> kopija reference. ;)
>>
>> To je točno ako ne radiš razliku između reference i pointera. Tvoje
>> objašnjenje nije korisno, jer "pass by reference" podrazumijeva
>> implicitnu referencu, a ne pointer.
>
> Pricam o Javi di taj izraz nije isti kao u C++, dakle na stacku ne stoji
> adresa reference (pointer), nego kopija reference (implicitna). Zato je
> meni to isto sto i "by value".
A ja samo kažem da se izraz "pass by reference" za Javu uopće ne bi smio
koristiti, jer "pass by reference" znači nešto sasvim drugo.
Ljudi ne objasne da se pod "pass by reference" podrazumijeva implicitna
referenca na varijablu i da ta referenca nema nikakve veze s referencom
na objekt koja je samo vrijednost te varijable.
<...>
> U oba tvoja slucaju se na stack stavlja ne 5, vec adresa od x, a to
> je 20.
>
> Terminologija koja nalaze da se drugi primjer zove "by reference" u
> Javi nema bas smisla, zar ne?
Nema. Nimalo. Jer Java nema pointere niti "pass by reference". :) Dakle,
ne možeš reći da "by reference" u Javi znači "by value". Ono što bi
ljudi trebali objasniti je upravo to da Java ni u kom slučaju parametre
ne prosljeđuje "by reference" i da "pass by reference" u Javi ne postoji.
Smola
>
> On 05.08.2010 23:27, Smola wrote:
>
> >> Pusti sad pointere. Pointer nije isto što i referenca.
> >
> > Uf. Meni je referenca adresa, a pointer je varijabla koja sadrzi tu
> > adresu, ok?
>
> Možda tebi. Pointer nije (svaka) varijabla koja sadrži referencu. Riječ
> pointer ili pokazivač se odnosi na specijalni tip podatka. Java nema
> pointere, iako bi po tvome bilo da je varijabla reference zapravo pointer.
Ti si ocito navikao na striktnu terminologiju vezanu za C++, zar ne? Ako
pocens pricati u kontekstu ostalih jezika, neovisno o sintaksi, ta
terminologija se svodi na istu stvar, a to je ta da se prenosi kopija
adrese na stack. Kako ces ti to nazvati ne znam, ali zasad to ljudi zovu
"by reference".
mimix
>
> Umjesto const mozes koristiti final u deklaraciji parametra.
Java "final" i C++ const nisu isto.
Nad objektom koji je final i dalje možeš pozvati metodu koja će
promjeniti njegovo interno stanje.
Zapravo ne bih znao reći što točno "final" garantira.
mimix
>
> Eto ga na. Nema. :)
>
> Evo probaj. Uzmi neku immutable klasu, npr. Integer.
>
> ++x;
> }
>
> Hmm. Ispisuje 0. Kako sad to, kad se objekti prosljeđuju by reference?
Ovaj ++x je zaparvo:
x = new Integer(x + 1);
Priznajem, nisam znao da je Number immutable. Ti si u metodi increment()
lokalnu referencu na neki Integer preusmjerio na neki drugi Integer. I
to ti je jasno.
> E sad, da je Java pass by reference za objekte kao što kažeš, tada bi se
> opisana promjena ulaznog argumenta x odrazila na i. No to se ne događa.
Ne bi. Ti ne šelješ referencu na referencu, nego samo referencu.
Ali mislim da nam je obojici jasno, samo nešto ne štima sa
terminologijom.
C:
void set_null_1(int *p) { p = NULL; }
void set_null_2(int **p) { *p = NULL; }
int k;
int *p;
p = &k;
set_null_1(p);
assert(p == NULL); // FAIL!
set_null_2(p);
assert(p == NULL); // SUCCESS!
> Ne događa se zato što je Java isključivo *PASS BY VALUE*. To ne znači da
> se cijeli objekt na neki način šalje by value,
Pass by value znači baš to i ništa drugo.
> već se by value šalje
> vrijednost varijable (koja je u slućaju objekta referenca na taj objekt
Znači šalješ referencu, a ne kopiju objekta.
Screamin Lord Byron
> In article <i3h0pb$un8$1...@news.metronet.hr>, sc...@min.dot says...
>>
>> On 05.08.2010 23:27, Smola wrote:
>>
>>>> Pusti sad pointere. Pointer nije isto što i referenca.
>>>
>>> Uf. Meni je referenca adresa, a pointer je varijabla koja sadrzi tu
>>> adresu, ok?
>>
>> Možda tebi. Pointer nije (svaka) varijabla koja sadrži referencu. Riječ
>> pointer ili pokazivač se odnosi na specijalni tip podatka. Java nema
>> pointere, iako bi po tvome bilo da je varijabla reference zapravo pointer.
>
> Ti si ocito navikao na striktnu terminologiju vezanu za C++, zar ne?
Mišljenja sam da te stvari moraju biti precizno definirane. I jesu. To
se ne odnosi samo na C++, već na programske jezike općenito i na ono što
se zove evaluation strategy.
> Ako
> pocens pricati u kontekstu ostalih jezika, neovisno o sintaksi, ta
> terminologija se svodi na istu stvar, a to je ta da se prenosi kopija
> adrese na stack. Kako ces ti to nazvati ne znam, ali zasad to ljudi zovu
> "by reference".
Ne znam tko to tako zove, ali to je krivo. Uvijek kada se prenosi
*kopija* vrijednosti (referenca[1] je vrijednost), onda je to by value.
Ako se, s druge strane, ne radi o kopiji vrijednosti, već o implicitnoj
referenci, onda je to by reference[2].
Neki jezici nemaju by reference (kao Java ili C), neki imaju (kao C++,
VB ili Perl). Tvrdnja da se to sve svodi na isto je potpuno beskorisna.
_________
1......http://en.wikipedia.org/wiki/Reference_(computer_science)
2......
http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_reference
Screamin Lord Byron
> Ovaj ++x je zaparvo:
> x = new Integer(x + 1);
>
> Priznajem, nisam znao da je Number immutable. Ti si u metodi increment()
> lokalnu referencu na neki Integer preusmjerio na neki drugi Integer. I
> to ti je jasno.
Da, baš zato sam dao primjer s immutable objektom, jer je on relevantan
za ovo o čemu pričamo. Nije sporno da mutable objektu možeš promijeniti
stanje, ali o tome ovdje nije riječ. Riječ je o onome što se događa na
stacku.
>
>> E sad, da je Java pass by reference za objekte kao što kažeš, tada bi se
>> opisana promjena ulaznog argumenta x odrazila na i. No to se ne događa.
>
> Ne bi. Ti ne šelješ referencu na referencu, nego samo referencu.
> Ali mislim da nam je obojici jasno, samo nešto ne štima sa
> terminologijom.
Nešto opasno ne štima s terminologijom. Vidi linkove koje sam dao Smoli.
Dakle. Još jednom. Referenca na objekt je nešto što nema veze s
referencom na koju se odnosi izraz "pass by reference". Prvo je
jednostavno nekakva vrijednost koja govori gdje se objekt nalazi na
heapu. Drugo je vrijednost varijable, koja je na stacku.
>> Ne događa se zato što je Java isključivo *PASS BY VALUE*. To ne znači da
>> se cijeli objekt na neki način šalje by value,
>
> Pass by value znači baš to i ništa drugo.
Vidi drugi link koji sam dao Smoli. Tamo također imaš objašnjeno i što
znači "pass by value" i vidjet ćeš da nisi u pravu.
Iz tog članka:
"The term "call-by-value" is sometimes problematic, as the value implied
is not the value of the variable as understood by the ordinary meaning
of value, but an implementation-specific reference to the value."
>> već se by value šalje
>> vrijednost varijable (koja je u slućaju objekta referenca na taj objekt
>
> Znači šalješ referencu, a ne kopiju objekta.
Šaljem kopiju nekakve vrijednosti, bila ona vrijednost primitivnog tipa
ili neka memorijska adresa na heapu (referenca na objekt), tak svejedno.
U ovom kontekstu, ne zanima nas heap, nego samo stack.
Zeljko Vrba
>
> Znači šalješ referencu, a ne kopiju objekta.
>
1) Java prosljedjuje SVE ISKLJUCIVO by value.
2) JAVA "REFERENCE" SU POINTERI. JEDINO cime se razlikuju od C-ovskih pointera
je da ne podrzavaju pointer aritmetiku; samim time se ponasaju isto kao, npr.,
pointeri u Pascalu.
U C-u je razlika izmedju f(x) i g(&x) ocita iz sintakse. U javi h(x) ponekad
odgovara C-ovskom f(x) [u slucaju kad imas primitivne tipove poput int i
float], a ponekad h(x) odgovara c-ovskom g(&x) [u slucaju da je x pointer na
neku klasu.]
Anyway, cijela stvar ne bi bila tako konfuzna da idioti u Sunu nisu pointere
preimenovali u reference [marketinski trik] kako bi privukli programere koji
smatraju da su pointeri u C-u "teski".
Na kraju zavrsis sa
Blah x = new Blah(12); // u C++-u bi napisao: Blah *x = new Blah(12);
int y = 13; // identicno kao u C++-u
U pozivu h(x) se prenosi kopija vrijednosti pointera x. I u Javi i u C++u.
Uf, kad vidim za kakvu abominaciju je Sun zasluzan, a koja je jos postala de
facto standard za uvod u programiranje na svjetskim sveucilistima, nekako mi
nije zao da su bankrotirali.
mimix
>
> 1) Java prosljedjuje SVE ISKLJUCIVO by value.
>
>
Znači kada u C++-u imaš
void h(Blah* b)
reči ćeš da se objekt prenosi by value?
Kako onda zoveš h(Blah b) da mi je znati.
Screamin Lord Byron
> 2) JAVA "REFERENCE" SU POINTERI. JEDINO cime se razlikuju od C-ovskih pointera
> je da ne podrzavaju pointer aritmetiku; samim time se ponasaju isto kao, npr.,
> pointeri u Pascalu.
Ja imam avion. Jedino po čemu se razlikuje od drugih aviona je to da
nema letne površine ni propelere. Samim time se ponaša isto kao avion
koji rula po pisti. Tu vrstu aviona proizvođač zove automobilom, kako bi
privukao ljude koji misle da je letjeti teško.
Screamin Lord Byron
> On 2010-08-06, Zeljko Vrba wrote:
>>
>> 1) Java prosljedjuje SVE ISKLJUCIVO by value.
>>
>> Blah x = new Blah(12); // u C++-u bi napisao: Blah *x = new Blah(12);
>>
>> U pozivu h(x) se prenosi kopija vrijednosti pointera x. I u Javi i u C++u.
>
> Znači kada u C++-u imaš
> void h(Blah* b)
> reči ćeš da se objekt prenosi by value?
Ti imaš problema s razumijevanjem riječi "value" u izrazu "pass by
value". Ovdje "value" nije objekt.
Nije li iz sintakse očito da ova metoda uopće ne prima objekt nego pointer?
> Kako onda zoveš h(Blah b) da mi je znati.
To je isto pass by value. C++ može instancirati objekt na stacku, pa je
u ovom slučaju "value" objekt.
mimix
>
> Ti imaš problema s razumijevanjem riječi "value" u izrazu "pass by
> value". Ovdje "value" nije objekt.
Ma OK. U javi je sve by value, pa se i tako i reference šalju by value.
To sam izjavio sada i nikad više. Uopče ne želi programirati u takvom
unakaženom svijetu kakav je vaš.
Screamin Lord Byron
> On 2010-08-07, Screamin Lord Byron wrote:
>>
>> Ti imaš problema s razumijevanjem riječi "value" u izrazu "pass by
>> value". Ovdje "value" nije objekt.
>
> Ma OK. U javi je sve by value, pa se i tako i reference šalju by value.
Tako je.
> To sam izjavio sada i nikad više. Uopče ne želi programirati u takvom
> unakaženom svijetu kakav je vaš.
A zakaj misliš da bilo koga ovdje zanima tvoja percepcija svijeta? O
tome možemo na hr.alt.filozofiranje.
Zeljko Vrba
> On 2010-08-06, Zeljko Vrba wrote:
>>
>> 1) Java prosljedjuje SVE ISKLJUCIVO by value.
>>
>> Blah x = new Blah(12); // u C++-u bi napisao: Blah *x = new Blah(12);
>>
>> U pozivu h(x) se prenosi kopija vrijednosti pointera x. I u Javi i u C++u.
>
> Znači kada u C++-u imaš
> void h(Blah* b)
> reči ćeš da se objekt prenosi by value?
>
>
> Kako onda zoveš h(Blah b) da mi je znati.
>
By value, naravno. Ovdje se zaista prenosi objekt.
Zeljko Vrba
objekta. Osnovne operacije nad pointerima su dodjeljivanje adrese nekog
drugog objekta ili pointera, te dereferenciranje. Takve pointere ima
puno jezika, a pointer aritmetika je specificna za C i C++ (i mozda jos
pokoji egzoticni, uz C# u unsafe modu.)
Uostalom: http://mindprod.com/jgloss/pointer.html
Pri dnu je citat J. Goslinga: An object is a class instance or an array. The
reference values (often just references) are pointers to these objects, and a
special null reference, which refers to no object.
Screamin Lord Byron
> On 2010-08-07, Screamin Lord Byron <sc...@min.dot> wrote:
>> On 06.08.2010 22:46, Zeljko Vrba wrote:
>>
>>> 2) JAVA "REFERENCE" SU POINTERI. JEDINO cime se razlikuju od C-ovskih pointera
>>> je da ne podrzavaju pointer aritmetiku; samim time se ponasaju isto kao, npr.,
>>> pointeri u Pascalu.
>>
>> Ja imam avion. Jedino po čemu se razlikuje od drugih aviona je to da
>> nema letne površine ni propelere. Samim time se ponaša isto kao avion
>> koji rula po pisti. Tu vrstu aviona proizvođač zove automobilom, kako bi
>> privukao ljude koji misle da je letjeti teško.
>>
> Razmisli jos jednom. Pointer je objekt koji sadrzi adresu nekog drugog
> objekta. Osnovne operacije nad pointerima su dodjeljivanje adrese nekog
> drugog objekta ili pointera, te dereferenciranje. Takve pointere ima
> puno jezika, a pointer aritmetika je specificna za C i C++ (i mozda jos
> pokoji egzoticni, uz C# u unsafe modu.)
>
> Uostalom: http://mindprod.com/jgloss/pointer.html
Sve to štima. Htio sam samo reći da je stvar u tome što reference u Javi
programer uopće ne može koristiti na način na koji koristi pointere u,
recimo, Pascalu ili bilo gdje drugdje gdje postoje pointeri. Apsolutno
mu ništa ne znače u tom smislu. Zbog toga mislim da je dobro da se zovu
tako kako se zovu i ne vjerujem da je tu marketing igrao bilo kakvu
ulogu. Osim toga:
"Pointers always point directly to data. References are usually
implemented as handles, not pointers. A handle is a pointer to a
pointer. This allows Objects to be moved around to compact fragmented
RAM without having to find and adjust all the pointers to those Objects."
> Pri dnu je citat J. Goslinga: An object is a class instance or an array. The
> reference values (often just references) are pointers to these objects, and a
> special null reference, which refers to no object.
Mislim da je to Greenova sprdačina na temu "old habits die hard" i
njegov kanadski humor[*]. U prvom citatu od istog autora (Goslinga)
stoji: "...because there are no pointers in Java".
----------
* .... http://bit.ly/cbljWn
Zeljko Vrba
>
> Sve to štima. Htio sam samo reći da je stvar u tome što reference u Javi
> programer uopće ne može koristiti na način na koji koristi pointere u,
> recimo, Pascalu ili bilo gdje drugdje gdje postoje pointeri. Apsolutno
>
povezanih lista ili binarnih stabala kao i pointeri u Pascalu ili u C-u. Da,
nemas pointer aritmetiku (malo koji jezik osim C familije ima), nemas ni
address of operator (posljedicno, ne mozes dobiti adresu primitivnih tipova,
ukljucivo referenci), ali to ne znaci da se reference na objekte ne ponasaju
kao pointeri na objekte.
>
> "Pointers always point directly to data. References are usually
> implemented as handles, not pointers. A handle is a pointer to a
> pointer. This allows Objects to be moved around to compact fragmented
> RAM without having to find and adjust all the pointers to those Objects."
>
Implementacijski detalj, nebitno. Handle je prije integer u globalni array
pointera. 64-bitni JVMovi imaju kompresiju pointera, heh.
Evo jos jedan tekst, vise za mimixa:
http://javadude.com/articles/passbyvalue.htm
Tu ces naci i link na sluzbenu Java dokumentaciju gdje stoji:
"The reference values (often just references) are pointers to these objects,
and a special null reference, which refers to no object"
--
Ako nije marketinski trik, zasto postoji NullPointerException a ne
NullReferenceException? ;)
Screamin Lord Byron
> Reference u pascalu su jednako upotrebljive za izgradnju
> povezanih lista ili binarnih stabala kao i pointeri u Pascalu ili u C-u. Da,
> nemas pointer aritmetiku (malo koji jezik osim C familije ima), nemas ni
> address of operator (posljedicno, ne mozes dobiti adresu primitivnih tipova,
> ukljucivo referenci), ali to ne znaci da se reference na objekte ne ponasaju
> kao pointeri na objekte.
To što se isto ponašaju na znači da su iz perspektive jezika isto.
Nego, možemo ovako zauvijek. Bi li se mogao složiti sa mnom ako kažem da
je ono što se u Javi zove referenca način skrivanja pointera od programera?
Dakle, nije sporno da će se referenca "ispod haube" svesti na pointer.
Sporno je samo to što kažeš da je Sun napravio pizdariju zato što je to
nazvao referencom. Ja mislim da je potpuno logično, opravdano i korisno
u Javi to *ne zvati* pointerom.
>> "Pointers always point directly to data. References are usually
>> implemented as handles, not pointers. A handle is a pointer to a
>> pointer. This allows Objects to be moved around to compact fragmented
>> RAM without having to find and adjust all the pointers to those Objects."
>>
> Implementacijski detalj, nebitno. Handle je prije integer u globalni
> array pointera. 64-bitni JVMovi imaju kompresiju pointera, heh.
Baš naprotiv. Ovo je vrlo bitno. Pointeri su implementacijski detalj. O
njima se brine JVM, a ne programer kao u drugim jezicima koji imaju
pointere.
> Tu ces naci i link na sluzbenu Java dokumentaciju gdje stoji:
>
> "The reference values (often just references) are pointers to these objects,
> and a special null reference, which refers to no object"
Sad si dao potpuno isti citat kao u prošlom postu. Znam da je to s
JLS-a. Tu ne piše da Java kao ima pointere, nego reference koje će se na
ovaj ili onaj način svesti na pointere na objekt u memoriji (vjerojatno
ne direktno, već preko handlea, a kako će to točno izgledati JLS ne
propisuje, već to ovisi o implementaciji, kao što si i sam rekao).
> Ako nije marketinski trik, zasto postoji NullPointerException a ne
> NullReferenceException? ;)
Teško da je to dokaz za marketinški trik. :) To je runtime i tu ima
smisla pričati o pointerima.
Screamin Lord Byron
> JLS-a. Tu ne piše da Java kao ima pointere, nego reference koje će se na
^^^^^^^^
Java kao programski jezik.
Zeljko Vrba
>
> To što se isto ponašaju na znači da su iz perspektive jezika isto.
>
Cijela prica je pocela o pass by value vs. pass by reference u Javi. Obojica
smo se slozili da Java ima iskljucivo pass by value, gdje su reference
vrijednosti koje se kopiraju okolo. Pozvana funkcija ne moze promijeniti
vrijednost reference-argumenta u pozivajucoj funkciji, ali moze promijeniti
objekt na koji referenca pokazuje. Upravo kao sto je to slucaj i u C-u.
Kak se to sad, "iz perspektive jezika", ponasa razlicito od pointera?
>
> Nego, možemo ovako zauvijek. Bi li se mogao složiti sa mnom ako kažem da
> je ono što se u Javi zove referenca način skrivanja pointera od programera?
>
Samo po imenu. Semantika im je identicna semantici pointera.
>
> nazvao referencom. Ja mislim da je potpuno logično, opravdano i korisno
> u Javi to *ne zvati* pointerom.
>
Ne slazem se jer samo stvara konfuziju, kao sto se vidi iz ovog threada.
>
> Baš naprotiv. Ovo je vrlo bitno. Pointeri su implementacijski detalj. O
> njima se brine JVM, a ne programer kao u drugim jezicima koji imaju
> pointere.
>
Brinuti se o tome kamo referenca pokazuje ili kamo pointer pokazuje je
identicna stvar. Ako mislis na GC, well.. ispada da se moras brinuti i o
referencama, samo na malo drugaciji nacin (WeakReference klasa; cesto x = null
(ekvivalentno free(x)) kako bi GC znao da moze pokupiti objekt). Ovo potonje
nije stvar reference ili pointeri, nego rucni memory management ili GC.
>
>> Ako nije marketinski trik, zasto postoji NullPointerException a ne
>> NullReferenceException? ;)
>
> To je runtime i tu ima smisla pričati o pointerima.
>
-cut-
Do ovog posta si djelovao lucidno.
Screamin Lord Byron
>> Nego, možemo ovako zauvijek. Bi li se mogao složiti sa mnom ako kažem da
>> je ono što se u Javi zove referenca način skrivanja pointera od programera?
>>
> Samo po imenu. Semantika im je identicna semantici pointera.
Kak im je semantika ista?
- nema pointer aritmetike
- moraju biti inicijalizirane
- moraju pokazivati na neki objekt (ili su null)
- ne mogu pokazivati na sredinu objekta
- ne pokazuju direktno na podatke u memoriji
- nema referenciranja i ručnog dereferenciranja
>> nazvao referencom. Ja mislim da je potpuno logično, opravdano i korisno
>> u Javi to *ne zvati* pointerom.
>>
> Ne slazem se jer samo stvara konfuziju, kao sto se vidi iz ovog threada.
Meni ne stvaraju konfuziju.
>>
>> Baš naprotiv. Ovo je vrlo bitno. Pointeri su implementacijski detalj. O
>> njima se brine JVM, a ne programer kao u drugim jezicima koji imaju
>> pointere.
>>
> Brinuti se o tome kamo referenca pokazuje ili kamo pointer pokazuje je
> identicna stvar.
Kao što piše u prvom tekstu na koji si dao link. Pointer pokazuje na
konkretne podatke u memoriji. Referenca u Javi pokazuje na 'apstraktni'
objekt. To uopće ne mora biti lokacija u memoriji gdje se podaci zaista
nalaze (može biti handle). Ne može se dogoditi da referenca pokazuje na
sredinu arraya ili na neku nasumičnu lokaciju u memoriji. To se može
dogoditi s poinerima, u Pascalu, u C-u, C++-u (čak i u C# u unsafe modu).
Nisam rekao ni mislio da programer ne mora brinuti na koji objekt će mu
referenca pokazivati, ali ne mora paziti hoće li to biti početak
objekta, sredina objekta ili neka nasumična memorijska lokacija.
> Ako mislis na GC, well..
Ne mislim na GC, ali kad ga već spominješ...
> ispada da se moras brinuti i o
> referencama, samo na malo drugaciji nacin (WeakReference klasa; cesto x = null
> (ekvivalentno free(x)) kako bi GC znao da moze pokupiti objekt). Ovo potonje
> nije stvar reference ili pointeri, nego rucni memory management ili GC.
Eh. GC u svakom trenutku može reclaimati bilo koji objekt na koji ne
postoji referenca i svaki izolirani otok objekata. Doduše, ne možeš biti
siguran kada će se to dogoditi tako da to nije ništa kao C-ov free().
Weak reference je nešto drugo. Primjer u kojem se koristi je WeakHashMap
kada se cijeli unos uklanja iz mape ako ključ nije u upotrebi (ne
postoji druga referenca na ključ osim reference iz mape -- mapa koristi
WeakReference objekte koji drže ključeve). Dakle, weak referenca je
referenca. Nije null, kao što sugeriraš. Možda bi ti to radije zvao weak
pointer.
Zeljko Vrba
>
>
kao ni u vecini drugih jezika koji imaju pointere.
>
> - moraju biti inicijalizirane
>
u C++-da, ali ne u Javi. sljedeci program se ispravno kompajlira i proizvede
class file:
class z
{
public static void main(String[] args)
{
Object x;
}
}
[default inicijalizacija je null]
>
> - moraju pokazivati na neki objekt (ili su null)
>
isto kao i u C-u, sve ostalo je undefined behaviour.
>
> - ne mogu pokazivati na sredinu objekta
>
Ne mogu ni u C-u osim ako ne castas pointer u neki drugi tip (npr. char*) pa
izvodis pizdarije.
>
> - ne pokazuju direktno na podatke u memoriji
>
Implementacijski detalj koji se nikako ne moze detektirati pure Java kodom.
Isto tako, implementacijski detalj koji se nikako ne moze detektirati pure C
kodom. Sam pojam "pokazivanje na podatke u memoriji" je jako tricky - sjeti se
samo segmentiranog protected moda x86 arhitekture gdje je (near) pointer samo
offset od pocetka segmenta, a za fizicku lokaciju segmenta u memoriji se brine
OS. Dakle OS moze, za program transparentno, premjestati segment po fizickoj
memoriji a da programu adresa 0x1234 ostaje 0x1234. Sto je u tom slucaju
0x1234? Referenca? Pointer? Offset? Sto je onda far pointer, npr.
0x17:0x1234 (selektor:offset)? Selektor je opet samo index u tablicu
deskriptora gdje zapravo pise bazna adresa segmenta. Itd, itd.
C se uredno izvrsava na arhitekturama sa nelinearnim adresnim modelima. JEDINO
sto C zahtijeva je da je pojedinacni objekt spremljen contiguously u memorji --
sto ce reci, da pointerom (char*)&neki_objekt mozes iterirati bajt po bajt po
objektu.
Referenca, sa gledista pure Java programa, pokazuje direktno na svoj objekt na
isti nacin kao sto C pointer pokazuje direktno na svoj objekt.
Dakle, "jednostavno" pitanje: sto tebi znaci "pokazivati direktno na podatke
u memoriji"?
>
> - nema referenciranja i ručnog dereferenciranja
>
Sto je referenciranje? Uzimanje adrese? Kakve veze ima nedostatak tog operatora
sa tipom podatka "pointer"? Jedina posljedica nedostatka address-of operatora
je jedan nacin manje kako stvoriti pointer tip podatka.
Sto je operator. ako ne rucno dereferenciranje? U C-u je operator -> skroz
suvisan, i za value tipove i za pointer tipove se glatko mogao koristiti
operator. posto kompajler prema deklaraciji varijabli u svakom trenutku zna
da li je s lijeve strane operatora . pointer ili konkretan objekt.
Dovraga, evo ti citat iz ANSI C99 standarda koji definira tip pointera pa vidi:
--
A pointer type may be derived from a function type, an object type, or an
incomplete type, called the referenced type. A pointer type describes an object
whose value provides a reference to an entity of the referenced type. A pointer
type derived from the referenced type T is sometimes called ‘‘pointer to T’’.
The construction of a pointer type from a referenced type is called ‘‘pointer
type derivation’’.
--
Primijeti da definicija ne spominje nista od gornjih svojstava koja si
nabrojao. U Javi mozes imati samo pointere na "object type" (by design), a
druga recenica TOCNO opisuje i reference u Javi. ["object" u kontekstu C-a
je sve sto zauzima neki storage]
>
> Kao što piše u prvom tekstu na koji si dao link. Pointer pokazuje na
> konkretne podatke u memoriji. Referenca u Javi pokazuje na 'apstraktni'
>
Prema kojoj to definiciji? C standard, kao sto sam gore citirao, definira
pointere drugacije.
I kako mozes, CISTIM JAVA KODOM, detektirati da li referenca pokazuje
"direktno" na podatke ili da je to samo index u neku internu JVM-ovu tablicu
koja konacno dovodi do "pravog" pointera. Ako mi napises cisti Java program
(dakle, nikakve C ekstenzije) koji moze detektirati ovu razliku, priznat cu da
Java reference ipak nisu pointeri.
>
> sredinu arraya ili na neku nasumičnu lokaciju u memoriji. To se može
> dogoditi s poinerima, u Pascalu, u C-u, C++-u (čak i u C# u unsafe modu).
>
Ok, pointeri u C-familiji jezika su puno mocniji, samim time i nesigurniji, od
pointera u ostalim jezicima (ukljucujuci Javu). Oko TOGA se mogu slozit.
Ali sve to sto si nabrojao ne ulazi u intrinsicnu definiciju pointera kao
sto je gore citirano iz C99 standarda.
Isto tako su svi gornji slucajevi undefined behaviour po C standardu, sto
moze znaciti da se moze desiti doslovno bilo sto. Za C je moguce napisati
VM (postoji ih nekoliko) koji ce, kao i Java, DEFINIRATI undefined behavior
tako da npr. uvijek sigurno zavrsi interpreter umjesto da dozvoli pisanje
po random memoriji. Which gives? Jesu li, unutar takvog C VM-a, pointeri
odjednom postali reference?
>
> Nisam rekao ni mislio da programer ne mora brinuti na koji objekt će mu
> referenca pokazivati, ali ne mora paziti hoće li to biti početak
> objekta, sredina objekta ili neka nasumična memorijska lokacija.
>
.. ja se ne sjecam kad sam zadnji put morao brinuti o tome. new / malloc
vracaju ispravne memorijske lokacije, & vraca ispravne memorijske lokacije.
Da, moras paziti na lifetime objekta cim imas pointere u igri, ali to je
opet prica o rucnom vs. automatskom memory managementu.
Apropos nasumicne adrese, stvar poput int *x = (int*)0xcafebabe sam zadnji put
napisao kad sam razvijao OS kernel (igracka, al nevermind).
Apropos pokazivanja u sredinu objekta, stvar poput char *p =
(char*)&some_double (npr.) pisem u low-level kodu, npr. racunanje hash
funkcije.
struct T *t; NE MOZE NIKADA I NIKAKO pokazivati u sredinu struct T objekta osim
ako ne radis stvari koje sam gore napisao (u drugom slucaju ti treba i cast
nazad).
Da, Java uvodi neka ogranicenja koja omogucuju da se bytecode verificira prije
ucitavanja i koja isto tako omogucuju relativno efikasno provjeravanje
ispravnosti pointera u run-timeu. Ali to su i dalje pointeri.
>
> Eh. GC u svakom trenutku može reclaimati bilo koji objekt na koji ne
> postoji referenca i svaki izolirani otok objekata. Doduše, ne možeš biti
> siguran kada će se to dogoditi tako da to nije ništa kao C-ov free().
>
Ako ne napravis p=null riskiras da objekt nikada ne bude pokupljen. Ako
napravis p=null, objekt ce biti pokupljen, ali ne znas kada. Dakle, p=null
je nedeterministicka verzija free()-a.
>
> WeakReference objekte koji drže ključeve). Dakle, weak referenca je
> referenca. Nije null, kao što sugeriraš. Možda bi ti to radije zvao weak
> pointer.
>
Da, boost biblioteka definira reference counted pointere (shared_ptr klasa) i
weak pointere (weak_ptr klasa) upravo kako bi se razrijesili problemi sa
cirkularnim zavisnostima i hash tablicama. Weak pointeri se, oh kako
neocekivano, ponasaju kao i weak reference. (modulo ref counted vs. pravi GC).
Wrbhhh
> Ti imaš problema s razumijevanjem riječi "value" u izrazu "pass by
> value". Ovdje "value" nije objekt.
Da ovak nekaj tvrdite na programerskim kolegijima na FER-u, ne biste se
dobro proveli. Hajmo uzeti jednostavan C primjer:
int a = 5; // na adresi 1000
foo(&a);
Da, broj 1000 se jest predao by value. Ali! Ono sto je zapisano na adresi
1000 se predalo _by reference_. Treba gledati smisao. Ti ovoj funkciji
predajes varijablu a. Istina, predajes je preko njezine adrese. Ali tebe u
funkciji zanima varijabla a, a ne zanima te nekakva adresa. Ti funkciji
predajes 1000 ne zato jer zelis predati 1000, nego upravo zato jer je 1000
adresa varijable a. I to je call by reference. Predajes varijablu a preko
reference. Ovdje treba gledati smisleno sto znaci "referenca", a ne nakakvu
konkretnu implementaciju. A ovdje referenca znaci "putokaz". Dakle, jedan
ogroman znak sa debelim slovima na kojem pise "eno, tamo se nalazi
varijabla a", tj. nesto sto te referira (usmjeruje, pokazuje) na varijablu
a. Treba gledati _smisao_.
Zeljko Vrba
> On Sat, 07 Aug 2010 14:38:27 +0200, Screamin Lord Byron wrote:
>
>> Ti imaš problema s razumijevanjem riječi "value" u izrazu "pass by
>> value". Ovdje "value" nije objekt.
>
> Da ovak nekaj tvrdite na programerskim kolegijima na FER-u, ne biste se
> dobro proveli. Hajmo uzeti jednostavan C primjer:
>
sljedece na folijama na predavanjima iz C-a:
int *x = (int*)malloc(...);
Je li to jos uvijek tako? To sto se predaje na FER-u nije nuzno dobra praksa
niti uvijek ima smisla.
> int a = 5; // na adresi 1000
> foo(&a);
>
> Da, broj 1000 se jest predao by value. Ali! Ono sto je zapisano na adresi
> 1000 se predalo _by reference_. Treba gledati smisao. Ti ovoj funkciji
>
Kompjuteri ne znaju nista o smislu, oni rade ono sto im se kaze. Funkcija
prima broj 1000. Tocka. Gornji kod je identican sljedecem:
int a = 5, *pa = &a;
foo(pa);
Nagradno pitanje 1: sto prima funkcija foo? Referencu na varijablu a ili
vrijednost nekog pointera (koji je slucajno inicijaliziran da pokazuje na a)?
Nagradno pitanje 2:
int *pa = malloc(sizeof(int));
foo(pa);
Sto u gornjem kodu prima funkcija foo? Referencu na neku varijablu (u tom
slucaju, koju?) ili vrijednost nekog pointera?
>
> predajes varijablu a. Istina, predajes je preko njezine adrese. Ali tebe u
> funkciji zanima varijabla a, a ne zanima te nekakva adresa. Ti funkciji
>
Ma tko veli da funkciju foo zanima variabla a? Uopce nije neuobicajeno pisati
kod poput
void foo(int x, int *p) { ... bar(p) ... }
gdje foo uopce ne pogleda *p. p moze zaista pokazivati na neku imenovanu
varijablu, moze pokazivati usred nekog arraya, moze pokazivati usred neke
anonimne strukture alocirane na heapu... Kojeg to smisla ima reci da je prvi
slucaj pass by reference, a sve ostalo pass by value pointera? Ma mislim.
>
> reference. Ovdje treba gledati smisleno sto znaci "referenca", a ne nakakvu
> konkretnu implementaciju. A ovdje referenca znaci "putokaz". Dakle, jedan
> ogroman znak sa debelim slovima na kojem pise "eno, tamo se nalazi
> varijabla a", tj. nesto sto te referira (usmjeruje, pokazuje) na varijablu
>
Tocno! Taj "putokaz" je upravo pointer, cija se vrijednost predaje funkciji ;)
Mozes i okrenuti sliku: foo(int *p) radi nesto sa pointerom na int (ili mozda
sa samim intom). Ponekad si lijen alocirati integer na heapu, pa ga alociras
lokalno na stacku i napravis foo(&a).
>
> a. Treba gledati _smisao_.
>
Gledanje i trazenje "smisla" tamo gdje ga nema samo stvara pogresnu sliku o
onome kako stvari zaista jesu - definitivno stetna situacija. C je ISKLJUCIVO
pass-by-value jezik. Ako ne vjerujes, pogledaj u ASNI C standard. Posaljem ti
kopiju na mail, ako te zaista zanima.
E sad, zasto uprava FER-a dozvoljava da se predaju ovakve besmislice -- to ti
ne mogu rec. Posalji pitanje prodekanu za nastavu. Preporucam anonimno. ;)
(vjerovat cu ti na rijec da se zaista ovako predaje, posto i sam prodjoh kroz
slicno, re. primjer sa castanjem povratne vrijednosti malloc-a [bilo ih je
vise, al taj mi je najvise ostao u sjecanju])
Da ne bi ispalo da vise vjerujes nekim bezveznjacima sa news-a nego profesorima
na FER-u, mozes pogledati ovdje:
http://zvrba.net/publications.html
I jos hrpa stvari kojima se bavim u trenutnoj firmi, ali o kojima nemrem pisat.
Mislim da znam o cemu pricam ;)
[Sad ozbiljno - osobno smatram da je nedopustivo da se na kakti vodecem
racunarskom studiju u RH predaju besmislice tipa pass by reference u C-u. ako
zele demonstrirati koncept, neka to rade u nekom jeziku koji to podrzava, tipa
Pascal ili C++.]
Dinko Korunic
> Da ovak nekaj tvrdite na programerskim kolegijima na FER-u, ne biste se
> dobro proveli. Hajmo uzeti jednostavan C primjer:
To najvise govori o tim kolegijima.
> int a = 5; // na adresi 1000
> foo(&a);
>
> Da, broj 1000 se jest predao by value. Ali! Ono sto je zapisano na adresi
[...]
> a. Treba gledati _smisao_.
Koji EPIC FAIL. To je call by value.
--
NAME:Dinko.kreator.Korunic DISCLAIMER:Standard.disclaimer.applies
ICQ:16965294 JAB:kreat...@jabber.org PGP:0xEA160D0B
HOME:http://dkorunic.net QUOTE:Eat.right.stay.fit.and.die.anyway
Igor Pozgaj
> E sad, zasto uprava FER-a dozvoljava da se predaju ovakve besmislice -- to ti
> ne mogu rec.
Ovo je jos kamilica :).
Objasnjenje ovoga o cemu raspravljate je da tamo (==ZPR) sve kompajliraju sa *C++*,
a ne *C* kompajlerom, pa im baca warning ako eksplicitno ne castaju void pointer u
nesto drugo ;). To tumaci ista ekipa koja kompajler poistovjecuje sa IDE-om (naravno,
onim majkrosoftovim).
O tome bi se dale napisati citave publikacije :), no zalosno je da sa FER-a, kakti
vodeceg IT faksa u regiji, izlazi kadar koji nikad nije cuo za version control,
makefileove, prakticki ne zna nista raditi bez IDE-a, o design patternima nije cuo
ni "d", ne zna napisati jednostavan regularan izraz itd. Gledano sa strane buducih
sistemasa je stanje jos komicnije, 90% ljudi nema pojma sto je storage, SAN, NAS,
ne zna sto je LDAP/AD, bore se sa osnovnim pojmovima poput DNS-a itd. Ali glavno da
zato znaju nacrtati shemu asinhronog turbogeneratora, malog Epsteinovog aparata i
pojacala u SZB ;). Svaka cast nekolicini dobrih predmeta (OOP, mreze, AFJJP,
paralelno itd), no vecina ostalog je lose, zastarjelo i nepotrebno.
> http://zvrba.net/publications.html
Faco. Jel dolazis u HR ove godine? :)
--
Igor Pozgaj | ipozgaj at gmail.com (GTalk / MSN)
ICQ: 126002505 | http://fly.srk.fer.hr/~ipozgaj
PGP: 0xEF36A092 | http://ipozgaj.blogspot.com
fb, lfm, li, dA | http://twitter.com/ipozgaj
Zeljko Vrba
> On 2010-08-09, Zeljko Vrba <mordor...@fly.srk.fer.hr> wrote:
>> E sad, zasto uprava FER-a dozvoljava da se predaju ovakve besmislice -- to ti
>> ne mogu rec.
>
> Ovo je jos kamilica :).
>
> Objasnjenje ovoga o cemu raspravljate je da tamo (==ZPR) sve kompajliraju sa
> *C++*, a ne *C* kompajlerom, pa im baca warning ako eksplicitno ne castaju
> void pointer u nesto drugo ;). To tumaci ista ekipa koja kompajler
> poistovjecuje sa IDE-om (naravno, onim majkrosoftovim).
>
>
> O tome bi se dale napisati citave publikacije :), no zalosno je da sa FER-a,
> kakti vodeceg IT faksa u regiji, izlazi kadar koji nikad nije cuo za version
-cut-
Jedna stvar je zastarjeli program, ono, kao "ok". Ali godinu za godinom
predavati studentima totalno netocne stvari je, da citiram Dinka, epic fail
tog zavoda. Ovo sto si ti nabrojao (version control, NAS, itd.) vise spada
u visu skolu. Moje je misljenje da fax MORA biti vise nastrojen prema
teoriji nego praksi.
Ja sam osobno na FER-u imao najvise koristi od cisto teoretskih predmeta. Ako
si se u stanju sam naucit programirat, vrijedi ic na FER samo radi ekipe koja
poducava fiziku, osnove elektrotehnike, elektroniku/sklopove i digitalnu,
matematike, obradu signala i SIS te Ribaricheve predmete. Ukratko, ZPM (1.
kat), ZESOI, ZEMRIS, te par katova C zgrade (fizika, OE). Ribaric, Baric,
Butkovic, Elezovic, Marangunic, Zubrinic, Skocir, Horvat i Henc, Jeren, Ilko -
LEGENDE. Njihovi predmeti su tough i naizgled nepotrebni jednom racunarcu, ali
ako ulozis trud da naucis to sto predaju, s tom kombinacijom uvoda u HW i
matematickom podlogom znas kako kompjuter radi od najnizeg nivoa i zaista imas
dovoljno dobru podlogu da sam da mozes nauciti raditi u bilo kojoj primjeni
racunarstva; sve konkretno sto znam od informatike, programiranja i
sistemasenja sam naucio sam, FER je tu bio vise-manje beskoristan. [Ovo je iz
perspektive mene diplomiranoga 2001. Kolko sam cuo, Bologna je uspjela
razvodniti i unistiti i ovih nekoliko dobrih kolegija :(]
>
> Faco. Jel dolazis u HR ove godine? :)
>
Eh, bio pocetkom 6. mjeseca. Tesko da cu opet prije iduce godine.
Screamin Lord Byron
>> - moraju biti inicijalizirane
>>
> u C++-da, ali ne u Javi. sljedeci program se ispravno kompajlira i proizvede
> class file:
>
> class z
> {
> public static void main(String[] args)
> {
> Object x;
> }
> }
>
> [default inicijalizacija je null]
Naravno da se ovo ne kompajlira jer x nije inicijaliziran. Lokalne
varijable nemaju default inicijalizaciju. To imaju samo varijable
instance i varijable static klase (fields).
>> - moraju pokazivati na neki objekt (ili su null)
>>
> isto kao i u C-u, sve ostalo je undefined behaviour.
Tako je, samo što Javine reference ne mogu prouzročiti undefined behavior.
>> - ne mogu pokazivati na sredinu objekta
>>
> Ne mogu ni u C-u osim ako ne castas pointer u neki drugi tip (npr. char*) pa
> izvodis pizdarije.
Nebitno. Bitno je da pointer u C-u može pokazivati na sredinu objekta.
<cut>
> Dakle, "jednostavno" pitanje: sto tebi znaci "pokazivati direktno na podatke
> u memoriji"?
Znači pokazivati na konkretan podatak, neki broj u memoriji (kako god
adresa izgledala, bilo to u stvarnoj ili virtualnoj memoriji, relativno
ili apsolutno). Mislim na sve ovo što si napisao gore.
S druge strane stoji pokazivanje na neku apstrakciju kao što je OOP
objekt (to je referenca). Dalje, sadržaj varijable reference u Javi je
nedostupan programeru (niti programera to zanima), za razliku od
sadržaja pointera u C-u kojeg programer može vidjeti.
JVM specifikacija ne propisuje internu strukturu objekata i način na
koji će JVM baratati s objektima. Iako je to u nekoj mjeri slično
structovima u C-u, C ipak dozvoljava uvid u izgled structa u memoriji,
pomoću pointera (kojih nema u Javi :) ).
Dakle, pojam varijable reference je na višoj razini apstrakcije od pojma
pointer.
>> - nema referenciranja i ručnog dereferenciranja
>>
> Sto je referenciranje? Uzimanje adrese? Kakve veze ima nedostatak tog operatora
> sa tipom podatka "pointer"? Jedina posljedica nedostatka address-of operatora
> je jedan nacin manje kako stvoriti pointer tip podatka.
Koji jezik koji ima pointere nema taj operator?
> Sto je operator. ako ne rucno dereferenciranje?
Automatsko dereferenciranje. :)
> U C-u je operator -> skroz
> suvisan, i za value tipove i za pointer tipove se glatko mogao koristiti
> operator. posto kompajler prema deklaraciji varijabli u svakom trenutku zna
> da li je s lijeve strane operatora . pointer ili konkretan objekt.
Da se operator -> izbacio to bi značilo automatsko dereferenciranje
u tom smislu. Doduše, još uvijek bi bilo nužno imati operator ručnog
dereferenciranja * za sve ostalo.
> Dovraga, evo ti citat iz ANSI C99 standarda koji definira tip pointera pa vidi:
>
> --
> A pointer type may be derived from a function type, an object type, or an
> incomplete type, called the referenced type. A pointer type describes an object
> whose value provides a reference to an entity of the referenced type. A pointer
> type derived from the referenced type T is sometimes called ‘‘pointer to T’’.
> The construction of a pointer type from a referenced type is called ‘‘pointer
> type derivation’’.
> --
>
> Primijeti da definicija ne spominje nista od gornjih svojstava koja si
> nabrojao. U Javi mozes imati samo pointere na "object type" (by design), a
> druga recenica TOCNO opisuje i reference u Javi. ["object" u kontekstu C-a
> je sve sto zauzima neki storage]
Ja tu nigdje ne vidim definiciju pointera.
>> Kao što piše u prvom tekstu na koji si dao link. Pointer pokazuje na
>> konkretne podatke u memoriji. Referenca u Javi pokazuje na 'apstraktni'
>>
> Prema kojoj to definiciji? C standard, kao sto sam gore citirao, definira
> pointere drugacije.
C standard *ne definira* što je to pointer. To mu nije cilj. Ono što si
citirao pokazuje samo da u C-u pointer može imati
tip. Nije to nikakva definicija pointera.
> I kako mozes, CISTIM JAVA KODOM, detektirati da li referenca pokazuje
> "direktno" na podatke ili da je to samo index u neku internu JVM-ovu tablicu
> koja konacno dovodi do "pravog" pointera. Ako mi napises cisti Java program
> (dakle, nikakve C ekstenzije) koji moze detektirati ovu razliku, priznat cu da
> Java reference ipak nisu pointeri.
Sasvim nebitno. Uopće nas ni u kom trenutku ne zanima sadržaj varijable
reference u Javi. U C-u nas to ponekad zanima i to je u C-u moguće
vidjeti (vrijednost pointera i broj na koji pokazuje).
> Isto tako su svi gornji slucajevi undefined behaviour po C standardu, sto
> moze znaciti da se moze desiti doslovno bilo sto. Za C je moguce napisati
> VM (postoji ih nekoliko) koji ce, kao i Java, DEFINIRATI undefined behavior
> tako da npr. uvijek sigurno zavrsi interpreter umjesto da dozvoli pisanje
> po random memoriji. Which gives? Jesu li, unutar takvog C VM-a, pointeri
> odjednom postali reference?
Nisu. Da bi postali reference, morao bi promijeniti jezik. Npr., kad bi
napravio C kompajler koji bi detektirao undefined behavior (a za to je
nužno sakriti pointere od programera), onda bi ih mogao tako nazvati.
No, to onda više ne bi bio C (nego nešto kao Java :)).
> Apropos nasumicne adrese, stvar poput int *x = (int*)0xcafebabe sam zadnji put
> napisao kad sam razvijao OS kernel (igracka, al nevermind).
Pod "nasumična adresa" sam mislio na wild pointere.
> Apropos pokazivanja u sredinu objekta, stvar poput char *p =
> (char*)&some_double (npr.) pisem u low-level kodu, npr. racunanje hash
> funkcije.
>
> struct T *t; NE MOZE NIKADA I NIKAKO pokazivati u sredinu struct T objekta osim
> ako ne radis stvari koje sam gore napisao (u drugom slucaju ti treba i cast
> nazad).
Ovo se kompajlira s dva warninga, ali se kompajlira. Znači može se.
char *tcp = t;
tcp++;
t = tcp;
Naposlijetku, i t i tcp su brojevi. Mogao sam napisati i:
struct T *t = 0x7fff9bef21d0;
i pogoditi u dio memorije koju zauzima neki struct T objekt, a koji ne
odgovara referenci na taj tip objekta u skladu s implementacijom.
To što se takve stvari obično ne rade i što je vjerojatnost da se to
ostvari mala ne znači da nije moguće u načelu, jer su pointeri brojevi.
Ovo pokazuje da ovaj pointer t može, a i ne mora biti referenca na neki
objekt tipa struct T iako pokazuje na dio memorije koji takav objekt
zauzima.
>> Eh. GC u svakom trenutku može reclaimati bilo koji objekt na koji ne
>> postoji referenca i svaki izolirani otok objekata. Doduše, ne možeš biti
>> siguran kada će se to dogoditi tako da to nije ništa kao C-ov free().
>>
> Ako ne napravis p=null riskiras da objekt nikada ne bude pokupljen.
Ako si referencu deklarirao i inicijalizirao unutar metode ili nekog
bloka metode, onda je objekt smeće kad metoda vrati ili baci exception
ili kad se blok izvrši (osim u slučaju literalnih stringova koji mogu
ostati na poolu, ali tu niti null ne mijenja stvar).
Ništa ne riskiraš.
Screamin Lord Byron
> instance i varijable static klase (fields).
Bah... static varijable klase.
Omadon
> Da ne bi ispalo da vise vjerujes nekim bezveznjacima sa news-a nego profesorima
> na FER-u, mozes pogledati ovdje:
>
> http://zvrba.net/publications.html
>
Opa doktore nisi se pohvalio, ali to je tek prvi kad ce drugi :-)
--
Dee Dee: You need a character too.
Dexter: I want to be Gygex, the 27th level warrior mage with
a class 18 soul-sucking-sword and...
Dee Dee: Here you go, you can be this guy.
Valarian: Well, it seems Hodo the furry footed burrower has joined our quest.
Zeljko Vrba
>
> Naravno da se ovo ne kompajlira jer x nije inicijaliziran. Lokalne
> varijable nemaju default inicijalizaciju. To imaju samo varijable
> instance i varijable static klase (fields).
>
anakin[1006] ~ % rm z.class; javac z.java
----------
1. WARNING in z.java (at line 5)
Object x;
^
The local variable x is never read
----------
anakin[1007] ~ % ls -l z.class
-rw-r--r-- 1 zvrba ifi-a 247 aug 9 18:02 z.class
>
> Nebitno. Bitno je da pointer u C-u može pokazivati na sredinu objekta.
>
Heh, ne moze, vidi dolje.
>
> Znači pokazivati na konkretan podatak, neki broj u memoriji (kako god
> adresa izgledala, bilo to u stvarnoj ili virtualnoj memoriji, relativno
> ili apsolutno). Mislim na sve ovo što si napisao gore.
>
Sa gledista Java programa, referenca pokazuje direktno na svoj objekt.
>
> S druge strane stoji pokazivanje na neku apstrakciju kao što je OOP
> objekt (to je referenca).
>
Epic fail. OOP objekt je isto komad podataka na nekom mjestu u memoriji.
Odustajem od daljnje diskusije oko ovoga. Ti izgleda nisi u stanju razluciti
abstract machine koji definira C i Java jezike od konkretnih implementacija
(neki procesor, npr. AMD Opteron i JVM).
>
> JVM specifikacija ne propisuje internu strukturu objekata i način na
> koji će JVM baratati s objektima.
>
O ali propisuje. Integeri su u dvojnom komplementu, FP brojevi su IEEE,
ostalo je implementation-defined, bas kao i u C-u.
>
> Da se operator -> izbacio to bi značilo automatsko dereferenciranje
> u tom smislu.
>
E ajme...
>
> Ja tu nigdje ne vidim definiciju pointera.
>
Druga recenica. Odlomak se nalazi u odjeljku "Types" koji opisuje sve
tipove dostupne C programu.
>
> C standard *ne definira* što je to pointer. To mu nije cilj. Ono što si
>
C standardu je cilj definirati semantiku pointera, kao sto je Java standardu
cilj definirati semantiku referenci. Semantika referenci je definirana rjecju
"pointer". Ironicno, u C standardu je obrnuto.
>
> Nisu. Da bi postali reference, morao bi promijeniti jezik. Npr., kad bi
> napravio C kompajler koji bi detektirao undefined behavior (a za to je
> nužno sakriti pointere od programera), onda bi ih mogao tako nazvati.
> No, to onda više ne bi bio C (nego nešto kao Java :)).
>
Moguce je napraviti interpreter za ANSI C koji ce ispravno izvrsiti svaki ANSI
C program koji se moze kompajlirati obicnim kompajlerom, ali ce isto tako u
runtimeu detektirati undefined behaviour, isto kao sto java detektira
NullPointerException u run-timeu. I gdje smo onda, sto su onda C-ovski
pointeri?
>
> Ovo se kompajlira s dva warninga, ali se kompajlira. Znači može se.
>
> char *tcp = t;
> tcp++;
> t = tcp;
>
Da, ali je tcp pointer na char. On ne pokazuje u sredinu nekog char objekta.
Da, C dozvoljava nesigurne castove koje Java nema. So?
Inace, i Java reference mogu pokazivati "u sredinu" nekog objekta:
class Test1
{
Test2 a, b, c;
Test2 GetB() { return b; }
}
Metoda GetB() vraca referencu na objekt koji je komponenta nekog drugog
objekta. Ako si pod "pokazivanjem na sredinu objekta" mislio na to.
>
> Naposlijetku, i t i tcp su brojevi. Mogao sam napisati i:
> struct T *t = 0x7fff9bef21d0;
>
E, pointeri nisu brojevi, nego imaju apstraktnu nespecificiranu
reprezentaciju. Da, u vecini implementacija se mogu bez gubitka informacija
pretvarati u integere i nazad, ali na nekim platformama gdje se C uredno
izvrsava, to nije moguce (neki egzoticni mainframeovi).
>
> To što se takve stvari obično ne rade i što je vjerojatnost da se to
> ostvari mala ne znači da nije moguće u načelu, jer su pointeri brojevi.
>
Nisu. Procitaj C standard.
>
> Ovo pokazuje da ovaj pointer t može, a i ne mora biti referenca na neki
> objekt tipa struct T iako pokazuje na dio memorije koji takav objekt
> zauzima.
>
Ovo samo pokazuje da C dozvoljava undefined behavior. Da se napraviti
interpreter koji takvo sto ne dozvoljava. (Tehnicki je i sama dodjela invalid
vrijednosti nekom pointeru UB - ne trebas dereferencirati pointer da bi
prouzrokovao UB).
Zeljko Vrba
>
> Opa doktore nisi se pohvalio, ali to je tek prvi kad ce drugi :-)
>
kavi :|
A drugi ce "malo" sacekat, sad imam super kul posao i neke druge stvari
imaju prioritet :-)
Nikola Ostrun
> On 2010-08-09, Screamin Lord Byron <sc...@min.dot> wrote:
[snip]
>> Ovo se kompajlira s dva warninga, ali se kompajlira. Znači može se.
>>
>> char *tcp = t;
>> tcp++;
>> t = tcp;
>>
> Da, ali je tcp pointer na char. On ne pokazuje u sredinu nekog char objekta.
> Da, C dozvoljava nesigurne castove koje Java nema. So?
>
> Inace, i Java reference mogu pokazivati "u sredinu" nekog objekta:
>
> class Test1
> {
> Test2 a, b, c;
> Test2 GetB() { return b; }
> }
>
> Metoda GetB() vraca referencu na objekt koji je komponenta nekog drugog
> objekta.
Ne, getB() neće vratiti referencu na objekt koji je komponenta
nekog drugog objekta (barem ne u smislu u kojem se ovdje govori o
sadržaju i sredinama objekata). Ako pretpostavimo da postoji
konstruktor u Test1 koji će napraviti
b = new Test2();
poprilično sam siguran da se prostor za njega neće alocirati bilo
gdje unutar prostora koji zauzima bilo koji objekt klase Test1 (a
kamoli točno na njegovoj sredini ;-) ).
> Ako si pod "pokazivanjem na sredinu objekta" mislio na to.
Toliko je očito što se misli po sredinom objekta da boli. OK npr.
Object k = new Object();
recimo da k sadrži 1000 i da objekt klase Object zauzima 500
bajtova. Želi se postići/misli se da k sadrži 1250.
Inače, slažem se da je Java pass by value, ali zbog referenci ima
toliko sličnosti sa pass by reference (ok, istina, swap funkcija u
Javi definitivno neće biti toliko elegantna kao u C++) poput toga da
u pozivatelju vidim promjene koje su načinjene u pozvanoj metodi*, da
na stogu ne vidim stanje objekta i sve to bez nekakvog posebnog truda
tj. emulacije pass by reference (kao u C-u). Sad, sve ovo se svodi na
pitanje (kao što je već netko primijetio) što je u
Object k = new Object();
bitnije sam k ili ono na što pokazuje? Za mene je ono na što pokazuje
i zbog toga nemam grižnju savjesti i nemirnog sna ako Javu smatram
pass by reference. ;-)
*) Izgleda da sam ja čudan, ali ja ne očekujem da ću vidjeti promjenu
na immutable objektu...
PS: Čudno da nitko do sada nije spomenuo, ali u The Java Programming
Language jasno piše da je Java pass by value.
--
VI = Virtually Incomprehensible.
Wrbhhh
> Koji EPIC FAIL. To je call by value.
A ja i dalje kazem da je to sivo podrucje... :)
http://en.wikipedia.org/wiki/Call_by_reference#Call_by_reference
"Even among languages that don't exactly support call-by-reference, many,
including C and ML, support explicit references (objects that refer to
other objects), such as pointers (objects representing the memory
addresses of other objects), and these can be used to effect or simulate
call-by-reference (but with the complication that a function's caller must
explicitly generate the reference to supply as an argument)."
Wrbhhh
> Kompjuteri ne znaju nista o smislu, oni rade ono sto im se kaze.
A cuj... Nekima je casa poluprazna, a nekima polupuna. Ako gledas striktno
implementaciju, ona jest call-by-value. Ali ako gledas semantiku (smisao)
iza toga (dakle, nesto sto nije usko vezano uz samo programiranje; u
pseudokodu npr.), onda je to call-by-reference.
Ako ti je cilj nauciti nekakav princip ili algoritam, bez ulazenja u
konkretnu implementaciju, ako se taj princip zove "call-by-reference" i ako
za alat uzmes npr. C, onda se taj princip moze vrlo dobro nauciti na taj
nacin.
Kako sam rekao, sve ovisi kako gledas na to. Ako gledas konkretnu
implementaciju, onda jest call-by-value. Ali ako gledas neki smisao koji
lezi iza toga (nesto sto racunalo ne poznaje, ali ljudi razumiju), onda je
to call-by-reference.
Tu moje sudjelovanje zavrsava. Pozdrav.
Omadon
A nis javi se kad navratis u domovinu...
Zeljko Vrba
>
> Toliko je očito što se misli po sredinom objekta da boli. OK npr.
>
> Object k = new Object();
>
> recimo da k sadrži 1000 i da objekt klase Object zauzima 500
> bajtova. Želi se postići/misli se da k sadrži 1250.
>
aritmetika (struct T *pt =...; ++pt) radi u jedinicama velicine objekta na koji
pointer pokazuje. Cast na char, pa brljanje po pointeru pa cast nazad na
struct T* je potencijalno undefined behavior [koji se MOZE detektirati u
run-timeu, jedino sto nitko ne izvrsava C u nekom VM-u ;)].
>
> tj. emulacije pass by reference (kao u C-u). Sad, sve ovo se svodi na
> pitanje (kao što je već netko primijetio) što je u
>
> Object k = new Object();
>
> bitnije sam k ili ono na što pokazuje? Za mene je ono na što pokazuje
>
Bitno je stvarno stanje stvari: k nije Object nego pointer. A stvarno stanje
stvari je bitno jer, ako poistovjetis[*] k sa objektom na koji pokazuje,
ocekuje te neugodno iznenadjenje:
SomeClass k1 = new SomeClass(), k2 = k1;
MutateClass(k2);
// k1 se promijenio!!
[*] Uopce ne znam kako interpretirati to pitanje "sto je bitnije?". Ako zelis
pisati kvalitetan kod, jedino bitno je da tocno razumijes semantiku abstract
machinea za koji pises program. Povodjenje za bilo kakvim relativizacijama i
aproksimacijama vodi bugovima jer pises kod za NEKI DRUGI abstract machine koji
se NE POKLAPA sa implementacijom koja ce izvrsavati napisani program.
(Da, cak i C standard definira C jezik kroz dopustene akcije apstraktnog stroja
koji izvrsava C konstrukte.)
>
> i zbog toga nemam grižnju savjesti i nemirnog sna ako Javu smatram
> pass by reference. ;-)
>
good for you.
>
> PS: Čudno da nitko do sada nije spomenuo, ali u The Java Programming
> Language jasno piše da je Java pass by value.
>
eto! \o/
Zeljko Vrba
>
> A nis javi se kad navratis u domovinu...
>
Nikola Ostrun
> On 2010-08-09, Nikola Ostrun <nikola.ost...@email.t-com.hr> wrote:
>
> > Toliko je očito što se misli po sredinom objekta da boli. OK npr.
>
> > Object k = new Object();
>
> > recimo da k sadrži 1000 i da objekt klase Object zauzima 500
> > bajtova. Želi se postići/misli se da k sadrži 1250.
>
> To nije moguce niti u C-u, osim ako ne koristis nesigurne castove.
Znači *moguće* je.
> Pointer
> aritmetika (struct T *pt =...; ++pt) radi u jedinicama velicine objekta na koji
> pointer pokazuje. Cast na char, pa brljanje po pointeru pa cast nazad na
> struct T* je potencijalno undefined behavior [koji se MOZE detektirati u
> run-timeu, jedino sto nitko ne izvrsava C u nekom VM-u ;)].
Biće i toga :D
> > tj. emulacije pass by reference (kao u C-u). Sad, sve ovo se svodi na
> > pitanje (kao što je već netko primijetio) što je u
>
> > Object k = new Object();
>
> > bitnije sam k ili ono na što pokazuje? Za mene je ono na što pokazuje
>
> Bitno je stvarno stanje stvari: k nije Object nego pointer.
No amen. I za većinu programera bitniji je objekt nego referenca
(*moji* podaci su u objektu) i ako pozvana metoda ima utjecaj na
pozivatelja, to ne može biti ništa drugo nego pass by reference (ok,
može biti jedna od par drugih (u ovom kontekstu kao jaje jajetu
sličnih metoda), ali sigurno ne može biti pass by value).
> A stvarno stanje
> stvari je bitno jer, ako poistovjetis[*] k sa objektom na koji pokazuje,
> ocekuje te neugodno iznenadjenje:
Ja imam dojam da ti upravo to nenamjerno radiš. Baš zbog toga što ne
poistovjećujem k i objekt na koji pokazuje me ponašanje Jave ne
iznenađuje i ne kanim preobraćat ljude koji vjeruju da Java (većim
dijelom) pass by reference.
>
> SomeClass k1 = new SomeClass(), k2 = k1;
> MutateClass(k2);
> // k1 se promijenio!!
>
> [*] Uopce ne znam kako interpretirati to pitanje "sto je bitnije?".
Prema nečemu moraš odrediti dali je jezik jedno ili drugo. U tom
smislu bitnije. Na kraju krajeva, moguće je od Jave napraviti čisti
pass by reference. Neš tipa
class RefereceUltimateEdition {
public Object obj;
}
kao argument svim metodama :-) Još da Java ima MOP pa da se da
naštimat da je pristup obj moguć i bez korištenja ".", di bi joj bio
kraj...
> Ako zelis
> pisati kvalitetan kod, jedino bitno je da tocno razumijes semantiku abstract
> machinea za koji pises program.
Tako je. I isto kao što se mora znati da će naivna implementacija
swap funkcije failat, mora se znati da će metoda kojoj proslijedim
svoj Vector napraviti izmjene na njemu koje ću u pozivatelju vidjeti
(ono što se očekuje od pass by reference ili pass by name).
Jednostavno imam dojam da situacija za prosječnog programera nije crno-
bijela.
> Povodjenje za bilo kakvim relativizacijama i
> aproksimacijama vodi bugovima jer pises kod za NEKI DRUGI abstract machine koji
> se NE POKLAPA sa implementacijom koja ce izvrsavati napisani program.
Slažem se, ali mislim da ti jednako toliko relativiziraš kao i
pozicija :-)
Dinko Korunic
> konkretnu implementaciju, ako se taj princip zove "call-by-reference" i ako
> za alat uzmes npr. C, onda se taj princip moze vrlo dobro nauciti na taj
> nacin.
Upravo je evidentno da je materijal koji se uci na faksu toliko misleading
da ljudi nalaze "call by reference" princip i tamo gdje ga nema. Python bi
bio lijep primjer "pass by reference" jezika, dok C to nije.
Kao sto ti je vec receno, to sto je prenesen pointer je svejedno pass by
value za sam pointer, nema veze sto pointer pokazuje na nesto i obavlja
"simulaciju" call by reference. Takodjer je bitno promijetiti da ne mozes
promijeniti vrijednost predanog pokazivaca, s obzirom da je njegova
vrijednost predana pri pozivu funkcije i da pozvana funkcija sadrzi samo
kopiju vrijednosti -- dakle to nikako nije referenca.
Takodjer, ta simulacija "call by refence" je jos evidentnija po tome sto
moras "posebno" oznaciti koristenje pointera f(&ptr) u pozivajucoj
funkciji te sa posebnom deklaracijom f(nesto *ptr) odnosno posebnim
pozivanjem *ptr u pozvanoj funkciji.
> Kako sam rekao, sve ovisi kako gledas na to. Ako gledas konkretnu
> implementaciju, onda jest call-by-value. Ali ako gledas neki smisao koji
> lezi iza toga (nesto sto racunalo ne poznaje, ali ljudi razumiju), onda je
> to call-by-reference.
Koristenje takve terminologije je totalno misleading i upravo radja
generacije koje misle da C moze imati call by reference.. ili da
programiraju u Microsoft Visual C++ *jeziku*.. ili da je C++ nadskup C-a
(o svakoj toj temi je svakih par godina diskusija na hr.org.fer, nove
generacije dolaze sa starim zabludama).
Ako je nesto samo losa simulacija neceg, onda je bolje takav primjer ne
davati studentima jer se upravo desi ovakva situacija.
Zeljko Vrba
>
> Prema nečemu moraš odrediti dali je jezik jedno ili drugo. U tom
>
rai
...
>To su otprilike najbitniji principi programiranja.
Pregršt korisnih informacija, hvala puno! :)
Poznato mi je još sa hcolinx da si vrlo iskusan programer, pa tvoje
postove čitam sa posebnom pozornošću :)
>Hm, u ovoj situaciji je IMHO, _jedina_ korist koju ces imati od tecaja da ces
>vjerojatno imati vise motivacije da redovito i konstantno radis. Ako se mozes
>sam motivirati da svaki dan po sat vremena citas knjigu, svaki drugi dan radis
>vjezbe jednako dugo kao sto bi radio i na predavanjima -- ne bacaj lovu na
>tecaj.
Svakako ću dobro morati razmisliti, u to nema sumnje. Imam još jedno
mjesec dana za razmisliti. Hvala puno još jednom na iscrpnim
informacijama.
Nikola Ostrun
> In hr.org.fer Wrbhhh <morgoth8...@gmail.com> wrote:
>> Ako ti je cilj nauciti nekakav princip ili algoritam, bez ulazenja u
>> konkretnu implementaciju, ako se taj princip zove "call-by-reference" i ako
>> za alat uzmes npr. C, onda se taj princip moze vrlo dobro nauciti na taj
>> nacin.
>
> Upravo je evidentno da je materijal koji se uci na faksu toliko misleading
> da ljudi nalaze "call by reference" princip i tamo gdje ga nema. Python bi
> bio lijep primjer "pass by reference" jezika, dok C to nije.
Samo da unesem jos pomutnje u raspravu, Python je po ovom pitanju
identican Javi. :D
>> Kako sam rekao, sve ovisi kako gledas na to. Ako gledas konkretnu
>> implementaciju, onda jest call-by-value. Ali ako gledas neki smisao koji
>> lezi iza toga (nesto sto racunalo ne poznaje, ali ljudi razumiju), onda je
>> to call-by-reference.
>
> Koristenje takve terminologije je totalno misleading i upravo radja
> generacije koje misle da C moze imati call by reference.. ili da
A propos terminologije, koje je originalno znacenje pass by reference?
Koliko vidim, to je poprilicno star pojam (u odnosu na C++, Perl i PHP),
pa...
foldoc.org ga definira tako da samo omogucuje daljnje raspravljanje u
nedogled (ovisno o vlastitim uvjerenjima):
An argument passing convention where the address of an argument variable
is passed to a function or procedure, as opposed to passing the value of
the argument expression. Execution of the function or procedure may have
side-effects on the actual argument as seen by the caller. The C
language's "&" (address of) and "*" (dereference) operators allow the
programmer to code explicit call-by-reference. Other languages provide
special syntax to declare reference arguments (e.g. ALGOL 60).
> Ako je nesto samo losa simulacija neceg, onda je bolje takav primjer ne
> davati studentima jer se upravo desi ovakva situacija.
:o)
rai
>rai wrote:
>> U samim početcima nije loše krenuti kroz neki program edukacije pa da
>> steknem temelje za samostalan rad.
>Evo ti moj savjet, pa ako se ispostavi da sam pomogao, mozes mi se
>zahvaliti npr. cevapima :)
Dobra ideja :)
>Dakle, ne kosta te puno da skines Javu (java.sun.com) i Eclipse
>(www.eclipse.org) i instaliras oboje.
>Nakon toga, odes na Google (www.google.com) i upises "java tutorial" i
>kliknes na (trenutno) drugi link
>(http://www.java2s.com/Tutorial/Java/CatalogJava.htm), pa onda krenes
>polako od prvog linka, pa nadalje.
>Takodjer, nije lose da nabavis neku knjigu o Javi (ima ih hrpa), a mozes
>i na HR jeziku ako se ne snalazis sa Engleskim, pa krenes po knjizi isto
>kao i po gornjem linku.
>Provedi tjedan-dva uz knjigu/tutorijal i vidi da li ti to ide ili ne
>ide. Ako ne ide, onda upisi tecaj i to je to.
Imam još jedno mjesec dana za razmišljanje :) U svakom slučaju hvala
puno!
rai
>On 04.08.2010 20:27, rai wrote:
>> Znači da ljudi lažu, što nije ništa neuobičajeno.
>Nije, ali iza laganja uvijek leži neki razlog, osim ako nisi patološki
>lažljivac. Razlog zašto lagati o iskustvu s nekim programskim jezikom na
>tečaju za programski jezik je izvan moje moći shvaćanja.
Možda ljudi to shvaćaju kao nekakav znak slabosti, tko zna...
>> Što se mojeg
>> iskustva tiče, imam gadan hendikep što na faksu nisam učio
>> programiranje, ali zato na poslu pišem Bash i Korn shell skripte za
>> Linux i AIX (a to su isto programski jezici, bez obzira što nisu neki
>> high level) pa ponešto znam od gore navedenih osnova.
>Nisam siguran da razumijem što podrazumijevaš pod to da nisu high level.
>Shell skripte su high level po definiciji.
Ne znam baš... kad vidim skripte svojih kolega UNIX administratora,
ispada da ove moje ipak jesu nešto low level u odnosu na njihove :)
Moje skripte su uglavnom za automatizaciju nekih rutinskih poslova,
tipa kopiranje logova, višestruka izmjena tekstualnih datoteka,
multiple rename datoteka i tako to... Koristim najosnovnije konstrukte
tipa if, elif, case, tu i tamo poneka while petlja, for petlja za
multiple rename datoteka, sve to u kombinaciji sa standardnim UNIX
alatima i programskim jezicima poput Sed, Awk, tu i tamo Perl. U
principu, baratam svim tim alatima + još poneki koliko mi je u praksi
potrebno jer zbog preopterećenošću operativnim poslovima nemam previše
vremena za samoeduciranje.
Ono što htjedoh reći jest da s obzirom na iskustva iznesena u ovom
threadu da sam dojma da imam solidne osnove za pratiti nastavu Java
edukacije.
>> Ajde ipak nešto od toga znam, ali svejedno nije loše to dobro
>> izvježbati prije no što se krene dalje. Međutim, jako je loše ako se
>> težište edukacije svede na to a ne na neke druge važnije stvari. Takve
>> stvari bi se po meni trebale predavati u nekom razumnom broju sati i
>> dobro to izvježbati kod kuće.
>A gle, kad se prvi put susrećeš s programiranjem, onda je to valjda
>teško i nerazumljivo, ali ako si prije pisao bilo kakav kod, sve što
>trebaš je naučiti novu sintaksu, a za to ti ne treba više od jednog
>popodneva.
Ma trebam ja dobro uvježbati i ovo što sada koristim... ne osjećam se
baš presigurno kad trebam nešto programirati, ipak ja tu vidim dosta
mjesta napretku. Ali mogu biti sretan barem zbog jedne stvari, unatoč
činjenici da mi je znanje skromno što se tiče programiranja, ipak ne
radim copy/paste tuđeg koda bez da uopće razumijem što sam kopirao,
što nerijetko vidim u praksi da čak i školovani programeri rade.
Toliko znanja imam da to znam prepoznati i ne mogu reći da je to tako
rijetka pojava, a iskustva sa prijašnjih radnim mjesta to samo
potvrđuju.
>> Nego, kakva je po tebi kvaliteta predavača? Meni se profil predavača
>> čini oke, ali svejedno mi je lijepo čuti iskustva iz prve ruke. Hvala.
>Bez sumnje, predavač je stručnjak za programiranje. Međutim, na mene
>nije ostavio dojam dobrog predavača.
Znači pričaš o Marijanu... dobro, ovo mi baš i nije utješno, ali...
>Dijelom zbog toga što nije imao
>pisanu pripremu za svaki sat, pa se događalo da neke važne stvari
>zaboravi spomenuti, a dijelom zbog samog stila predavanja koji meni nije
>odgovarao, s čestim nepotrebnim digresijama.
Hm... nije imao pisane pripreme... to baš i nije dobro. Ako se ne
varam negdje sam pročitao da drži vježbe na TVZ-u pa mi je zato malo
čudno da nema toliko iskustva, ali možda se je malo istrenirao do
sada.
>To ne znači da neće
>odgovarati nekom drugom. Evo, jedan od kolega s tečaja mi je rekao da
>baš odlično predaje. Doduše, taj kolega je bio jedan od onih koji su
>odustali. :)
Hm... :)
mimix
>
> Koristenje takve terminologije je totalno misleading i upravo radja
> generacije koje misle da C moze imati call by reference.. ili da
> programiraju u Microsoft Visual C++ *jeziku*.. ili da je C++ nadskup C-a
Nije bitno što generacije prvotno misle, bitno je koliko im minuta treba
da uvide da su u krivu.
Prirodno je pomisliti da je C++ nadskup C-a i gotovo nemoguće tako nešto
i dalje tvrditi onome tko je proveo i samo par minuta proučavajući jedan
i drugi.
Da se vratim na temu:
void foo(int &bar);
int b;
foo(b);
Je li onda barem ovo call by reference (C++)?
Mislim da svaka početnička knjiga koja se bavi C-om, C++-om ili Javom
tvrdi da je eksplicitno proslijeđivanje kopije reference na podatak
"call by reference". Nije to nešto što je na FER-u izmišljeno.
Čudno je to kako se autori knjiga, profesori, znantvene ustanove i
profesionalci (sve odreda autoriteti za mene) ne mogu složiti kako se
ova stvar zove (da, problem je samo u nomenklaturi, svi dobro znamo kako
stvar radi). Nisu računalne znanosti baš tako nova disciplina. Konačno,
jezici o kojima se govori postoje već nekoliko desetljeća.
--
Milan Mimica
http://sparklet.sf.net
Screamin Lord Byron
> On 2010-08-09, Screamin Lord Byron <sc...@min.dot> wrote:
>>
>> Naravno da se ovo ne kompajlira jer x nije inicijaliziran. Lokalne
>> varijable nemaju default inicijalizaciju. To imaju samo varijable
>> instance i varijable static klase (fields).
>>
> Huh, jesi li uopce probao? Ja naime jesam i kompajlira se:
>
> anakin[1006] ~ % rm z.class; javac z.java
> ----------
> 1. WARNING in z.java (at line 5)
> Object x;
> ^
> The local variable x is never read
> ----------
> anakin[1007] ~ % ls -l z.class
> -rw-r--r-- 1 zvrba ifi-a 247 aug 9 18:02 z.class
Znam što sam rekao. Pogledaj malo taj .class fajl. Ono što se ne koristi
*ne kompajlira se*.
Da. Dobiješ .class, ali nutra nema ni traga tvojoj deklaraciji objekta.
Pokušaj sad pozvati neku metodu od o i kompajler će ti javiti grešku jer
o nije inicijaliziran.
Kompajliraj ovo u nekom drugom direktoriju:
class z {
public static void main(String[] args) { }
}
i usporedi dobiveni .class fajl s tvojim. Vidjet ćeš da su *identični*.
Probaj sad:
class z {
public static void main(String[] args) {
Object o = null;
}
}
pa pogledaj .class. E, tek sad je o unutra.
>> S druge strane stoji pokazivanje na neku apstrakciju kao što je OOP
>> objekt (to je referenca).
>>
> Epic fail. OOP objekt je isto komad podataka na nekom mjestu u memoriji.
> Odustajem od daljnje diskusije oko ovoga. Ti izgleda nisi u stanju razluciti
> abstract machine koji definira C i Java jezike od konkretnih implementacija
> (neki procesor, npr. AMD Opteron i JVM).
Jesi siguran? Molim te, pročitaj barem još ovaj post prije nego što
odustaneš od rasprave, da vidiš na što mislim, jer se očito ne razumijemo.
>> JVM specifikacija ne propisuje internu strukturu objekata i način na
>> koji će JVM baratati s objektima.
>>
> O ali propisuje. Integeri su u dvojnom komplementu, FP brojevi su IEEE,
> ostalo je implementation-defined, bas kao i u C-u.
"3.7 Representation of Objects
The Java virtual machine does not mandate any particular internal
structure for objects."
Kad kažem objekt mislim na Object. Ne mislim na primitive. BTW, FP je
garantirano IEEE 754 samo uz ključnu riječ strictfp.
>> Da se operator -> izbacio to bi značilo automatsko dereferenciranje
>> u tom smislu.
>>
> E ajme...
Kaj sad e ajme? Da je napravljen kompajler koji ima mehanizam koji sam
odlučuje treba li to s lijeve strane točke dereferencirati ili ne, to bi
značilo automatsko dereferenciranje za taj slučaj, prema definiciji
riječi automatski.
automatski (pridjev):
koji radi, djeluje pomoću podešenog mehanizma, tako da skraćuje neke
radnje
http://hjp.srce.hr/index.php?show=search_by_id&id=e1xuXw%3D%3D
>> Ja tu nigdje ne vidim definiciju pointera.
>>
> Druga recenica. Odlomak se nalazi u odjeljku "Types" koji opisuje sve
> tipove dostupne C programu.
Ovo?
"A pointer type describes an object
whose value provides a reference to an entity of the referenced type."
Tu nema ništa o semantici pointera kao podatkovnog tipa, već je riječ o
tipu tog podatkovnog tipa. Da, to je isto kao tip reference u Javi. Kako
bi ti rekao, so? :)
>> C standard *ne definira* što je to pointer. To mu nije cilj. Ono što si
>>
> C standardu je cilj definirati semantiku pointera, kao sto je Java standardu
> cilj definirati semantiku referenci. Semantika referenci je definirana rjecju
> "pointer". Ironicno, u C standardu je obrnuto.
Ironično je samo ako općeniti pojam reference koji se nalazi u C
standardu izjednačiš s pojmom reference koji se nalazi u Java
specifikaciji. OK, slažem se da taj dio nekome može biti zbunjujuć. Kad
se u C standardu priča o referenci, tu se misli na referencu u općenitom
smislu, odnosno na neku vrijednost koja predstavlja lokaciju objekta.
Problematično je samo to što Java u određenoj mjeri redefinira taj
pojam, budući da referencom zove svoj integralni tip podataka. Ti kažeš
da je to u Javi isto što i pointer, a ja kažem da ga je bolje ne
nazivati tako jer mu fali "konkretnost" pointera (no mogu se složiti da
ni "referenca" nije najsretniji izbor). Pod "konkretnost" mislim na
mogućnosti manipulacije koje imaš s pointerima, a nemaš s Javinim
referencama. Stoga je Javina referenca apstraktniji pojam od pointera u
drugim jezicima.
>> Nisu. Da bi postali reference, morao bi promijeniti jezik. Npr., kad bi
>> napravio C kompajler koji bi detektirao undefined behavior (a za to je
>> nužno sakriti pointere od programera), onda bi ih mogao tako nazvati.
>> No, to onda više ne bi bio C (nego nešto kao Java :)).
>>
> Moguce je napraviti interpreter za ANSI C koji ce ispravno izvrsiti svaki ANSI
> C program koji se moze kompajlirati obicnim kompajlerom, ali ce isto tako u
> runtimeu detektirati undefined behaviour, isto kao sto java detektira
> NullPointerException u run-timeu. I gdje smo onda, sto su onda C-ovski
> pointeri?
Ne, ne i ne. Glavna razlika je to što se velika većina onoga što u C-u
može prouzročiti UB u Javi riješeno u samom jeziku, odnosno kod
kompajliranja, a ne u runtimeu.
Za isti efekt morao bi debelo preraditi ANSI C i napisati kompajler za
takav kod, ne interpretirati ANSI C i samo detektirati UB prilikom
runtimea.
Sad je pravi trenutak :) da se malo vratim na ono što sam prije napisao,
na što je tvoj jedini komentar bio da sam prestao biti lucidan. Zašto
NullPointerException a ne NullReferenceException.
Upravo se radi o runtimeu. Kao što znaš, Java interpreter ne
interpretira Java kod, već kompajlirani intermediate kod.
Dakle, kad bi napisao interpreter za ANSI C jezik koji bi detektirao UB
u runtimeu, tada bi još uvijek ti C pointeri bili pointeri isto kao što
su pointeri u kompajliranom kodu za neku konkretnu implementaciju.
Analogno tome, u Javinom bytecodeu su to također pointeri (JVM
specifikacija kaže reference (da bude dosljedna jeziku), ali naglašava:
"Values of type reference can be thought of as pointers to objects").
Ako hoćeš manipulirati njima na način kao u C-u, morao bi brljati po JVM
bytecodeu ili napisati kompajler koji će C(++) program kompajlirati u
JVM bytecode. Zapravo ne moraš, to već postoji:
(primijeti da se C++ ne kompajlira direktno u bytecode, nego prvo u MIPS
binary, pa onda u bytecode)
Naravno da je i dalje nemoguće detektirati UB kod kompajliranja i da se
pointeri iz C++ jezika nisu magično pretvorili u ono što se u
programskom jeziku Java zove referenca.
>> Ovo se kompajlira s dva warninga, ali se kompajlira. Znači može se.
>>
>> char *tcp = t;
>> tcp++;
>> t = tcp;
>>
> Da, ali je tcp pointer na char. On ne pokazuje u sredinu nekog char objekta.
> Da, C dozvoljava nesigurne castove koje Java nema. So?
Java ne dozvoljava konverziju nekompatibilnih tipova referenci, ali to
ne znači da je konverzija kompatibilnih tipova referenci uvijek sigurna
i to je jedina stvar vezana uz cast koja se u Javi ne može riješiti kod
kompajliranja (pa imamo ClassCastException). Budući da u C-u i C++-u
uvijek možeš raditi eksplicitni cast nekompatibilnih tipova, *jedini*
način da detektiraš UB je, kao što si rekao, u runtimeu.
>
> Inace, i Java reference mogu pokazivati "u sredinu" nekog objekta:
>
> class Test1
> {
> Test2 a, b, c;
> Test2 GetB() { return b; }
> }
>
> Metoda GetB() vraca referencu na objekt koji je komponenta nekog drugog
> objekta. Ako si pod "pokazivanjem na sredinu objekta" mislio na to.
Ehm. Na koji način ova metoda metoda radi išta slično onome što sam gore
napisao? Ova metoda vraća null za bilo koji objekt klase Test1. null
sigurno nije dio bilo koje instance Test1.
Čak da vraća referencu na neki objekt inicijaliziran u objektu klase
Test1, ta referenca *nije komponenta tog objekta*. Komponenta tog
objekta bi bila kada bi vratio *pointer na b*, odnosno memorijsku
lokaciju od b, ne sadržaj b-a.
Tu si sad napravio istu grešku kao oni koji misle da je Java
pass-by-reference zato što prosljeđuje referencu na objekt.
>> Naposlijetku, i t i tcp su brojevi. Mogao sam napisati i:
>> struct T *t = 0x7fff9bef21d0;
>>
> E, pointeri nisu brojevi, nego imaju apstraktnu nespecificiranu
> reprezentaciju. Da, u vecini implementacija se mogu bez gubitka informacija
> pretvarati u integere i nazad, ali na nekim platformama gdje se C uredno
> izvrsava, to nije moguce (neki egzoticni mainframeovi).
Dobro, nisu brojevi, ali se uvijek mogu prikazati kao broj i ovo mogu
napraviti bez obzira na implementaciju (uz adekvatan tip)
"A pointer may be converted to an integral type large enough to hold it;
the required size is implementation-dependent.
...
An object of integral type may be explicitly converted to a pointer."
--K&R, The C Programming Language, Second Edition, str. 199
>> Ovo pokazuje da ovaj pointer t može, a i ne mora biti referenca na neki
>> objekt tipa struct T iako pokazuje na dio memorije koji takav objekt
>> zauzima.
>>
> Ovo samo pokazuje da C dozvoljava undefined behavior. Da se napraviti
> interpreter koji takvo sto ne dozvoljava. (Tehnicki je i sama dodjela invalid
> vrijednosti nekom pointeru UB - ne trebas dereferencirati pointer da bi
> prouzrokovao UB).
Da se napraviti interpreter, ali ne kompajler koji detektira UB, jer
naravno da ne možeš znati je li vrijednost valjana prilikom kompajliranja.
Zeljko Vrba
>
> Da se vratim na temu:
> void foo(int &bar);
> int b;
> foo(b);
>
> Je li onda barem ovo call by reference (C++)?
>
promijenit da pokazuje na neki drugi objekt. To je onak, litmus test za
reference vs. pointere: ako se varijabla moze postaviti da pokazuje na
neki drugi objekt, to je pointer.
Konkretno, kad unutar foo() napravis bar=12, promijenit ce se b; nece referenca
pokazivat na neku drugu varijablu. Stovise, NEMOGUCE je (u okviru standardnog
C++ jezika) napraviti da bar pokazuje na neki drugi int. Unutar foo, &bar ce
biti tipa int* i vratiti istu vrijednost i kao &b izvan. Kad bi bar bio
pointer, &bar bi bio tipa int** i imao razlicitu vrijednost od &b izvan.
Inace, ako si upoznat sa UNIX filesystemom:
referenca : pointer = hard-link : soft-link
Analogija je prilicno jaka:
Hard-link 'pokazuje' [*] na vec postojeci fajl, ne moze biti invalid, ne mozes
ih koristiti da napravis cirkularne zavisnosti, i ne mozes razlikovati
"originalni" fajl i "hard-link". [*] 'pokazuje' u navodnicima jer nisi stvorio
novi objekt u FS-u (inode), vec samo novo ime za vec postojeci fajl. Oba imena
se resolvaju na isti inode.
Soft-link moze pokazivati na nepostojece fajlove (analogno null / invalid
pointerima), mozes napraviti cirkularne zavisnosti kako god te volja, i mozes
razlikovati "originalni" fajl i "soft-link". Soft link stvara i novo ime i novi
objekt (fajl) tipa "soft link", a sadrzaj tog objekta je path do target
fajla. Samim time soft-link i originalni fajl imaju i razlicite inodove.
Dinko Korunic
> Analogija je prilicno jaka:
Odlicna je analogija, stujem :)
Screamin Lord Byron
> Ma trebam ja dobro uvježbati i ovo što sada koristim... ne osjećam se
> baš presigurno kad trebam nešto programirati, ipak ja tu vidim dosta
> mjesta napretku. Ali mogu biti sretan barem zbog jedne stvari, unatoč
> činjenici da mi je znanje skromno što se tiče programiranja, ipak ne
> radim copy/paste tuđeg koda bez da uopće razumijem što sam kopirao,
> što nerijetko vidim u praksi da čak i školovani programeri rade.
> Toliko znanja imam da to znam prepoznati i ne mogu reći da je to tako
> rijetka pojava, a iskustva sa prijašnjih radnim mjesta to samo
> potvrđuju.
>
>>> Nego, kakva je po tebi kvaliteta predavača? Meni se profil predavača
>>> čini oke, ali svejedno mi je lijepo čuti iskustva iz prve ruke. Hvala.
>> Bez sumnje, predavač je stručnjak za programiranje. Međutim, na mene
>> nije ostavio dojam dobrog predavača.
>
> Znači pričaš o Marijanu... dobro, ovo mi baš i nije utješno, ali...
Da. Gle, čovjek se stvarno trudi i zna, jedino, previše je dopuštao da
ga se prekida nerelevantnim pitanjima, pa bi se tako često odlutalo u
neku temu koja nije tema predavanja ili bi se išlo ponavljati staro
gradivo kada je bilo predviđeno nešto drugo, iako je za ovo drugo
zaslužna grupa koja se nije bog zna što trudila. Nije sad da zastupam
tiraniju, ali bilo bi bolje da je bio malo stroži po tom pitanju. Nu, to
je samo moje mišljenje. Inače, moguće ga je uvijek bilo cimnuti i
mailom, na koji bi uvijek odgovorio.
> Ako se ne
> varam negdje sam pročitao da drži vježbe na TVZ-u pa mi je zato malo
> čudno da nema toliko iskustva, ali možda se je malo istrenirao do
> sada.
A moguće. Čak ne mislim da je to stvar njegovog iskustva kao predavača,
više stvar zrelosti samog tečaja. Kao što rekoh, ja sam bio u jednoj od
prvih grupa. Valjda su u međuvremenu naučili nekog vraga.
>
>> To ne znači da neće
>> odgovarati nekom drugom. Evo, jedan od kolega s tečaja mi je rekao da
>> baš odlično predaje. Doduše, taj kolega je bio jedan od onih koji su
>> odustali. :)
>
> Hm... :)
Uvijek ostaje mogućnost da je on odustao iz nekog desetog razloga. :)
Zeljko Vrba
>
> Problematično je samo to što Java u određenoj mjeri redefinira taj
> pojam, budući da referencom zove svoj integralni tip podataka. Ti kažeš
> da je to u Javi isto što i pointer, a ja kažem da ga je bolje ne
> nazivati tako jer mu fali "konkretnost" pointera (no mogu se složiti da
> ni "referenca" nije najsretniji izbor). Pod "konkretnost" mislim na
> mogućnosti manipulacije koje imaš s pointerima, a nemaš s Javinim
> referencama. Stoga je Javina referenca apstraktniji pojam od pointera u
> drugim jezicima.
>
>
> Ne, ne i ne. Glavna razlika je to što se velika većina onoga što u C-u
> može prouzročiti UB u Javi riješeno u samom jeziku, odnosno kod
> kompajliranja, a ne u runtimeu.
>
Nesto je, ali ne sve. Recimo, SML ima reference (koje su immutable! - jednom
se postavi i zauvijek pokazuje na svoj objekt) i tamo su SVI problemi koji mogu
dovesti do UB rijeseni u jeziku. Tamo je takvo sto opravdano zvati
referencama.
U Javi se ipak u run-timeu detektira null pointer exception i bad cast (ili
kako se vec zove) exception. A bad cast je upravo ekvivalentno primjeru kad se
u C-u char* casta na proizvoljni tip.
>
> Dakle, kad bi napisao interpreter za ANSI C jezik koji bi detektirao UB
> u runtimeu, tada bi još uvijek ti C pointeri bili pointeri isto kao što
> su pointeri u kompajliranom kodu za neku konkretnu implementaciju.
>
Cek, a sto s tvojim ranijim argumentom o tome kako su reference dupli pointeri,
handleovi u neku tablicu pravih pointera itd. Sad malo proturjecis samom sebi.
>
> Analogno tome, u Javinom bytecodeu su to također pointeri (JVM
> specifikacija kaže reference (da bude dosljedna jeziku), ali naglašava:
> "Values of type reference can be thought of as pointers to objects").
>
\o/
>
> Ako hoćeš manipulirati njima na način kao u C-u, morao bi brljati po JVM
> bytecodeu ili napisati kompajler koji će C(++) program kompajlirati u
> JVM bytecode. Zapravo ne moraš, to već postoji:
>
IIRC, JVM nema instrukcije koje dozvoljavaju brljanje po referencama kao sto
mozes brljati po pointerima u C-u.
>
> http://nestedvm.ibex.org/
>
> (primijeti da se C++ ne kompajlira direktno u bytecode, nego prvo u MIPS
> binary, pa onda u bytecode)
>
Taj bytecode ne brlja po referencama nego koristi int[][] array za
reprezentaciju memorije (pogledah prezentaciju na siteu).
>
>>
>> Inace, i Java reference mogu pokazivati "u sredinu" nekog objekta:
>>
>> class Test1
>> {
>> Test2 a, b, c;
>> Test2 GetB() { return b; }
>> }
>>
>> Metoda GetB() vraca referencu na objekt koji je komponenta nekog drugog
>> objekta. Ako si pod "pokazivanjem na sredinu objekta" mislio na to.
>
> Ehm. Na koji način ova metoda metoda radi išta slično onome što sam gore
> napisao? Ova metoda vraća null za bilo koji objekt klase Test1. null
> sigurno nije dio bilo koje instance Test1.
>
Radi kratkoce sam izostavio ostatak klase koji na neki nacin inicijalizira
a, b i c.
>
> Čak da vraća referencu na neki objekt inicijaliziran u objektu klase
> Test1, ta referenca *nije komponenta tog objekta*. Komponenta tog
>
Sto onda *jesu* komponenta objekta Test1 ako ne reference na a, b i c?
>
> objekta bi bila kada bi vratio *pointer na b*, odnosno memorijsku
> lokaciju od b, ne sadržaj b-a.
>
Pa GetB() to i vraca - referencu/pointer na b a ne sadrzaj b-a. Referenca se
pretvara u sadrzaj tek kad nad njom upotrijebis operator dereferenciranja (.).
A operator dereferenciranja obavi tocno to - upotrijebi vrijednost reference
da nadje gdje je objekt fizicki spremljen i dobavi podatak iz njega.
>
> Dobro, nisu brojevi, ali se uvijek mogu prikazati kao broj i ovo mogu
> napraviti bez obzira na implementaciju (uz adekvatan tip)
>
> "A pointer may be converted to an integral type large enough to hold it;
> the required size is implementation-dependent.
> ...
> An object of integral type may be explicitly converted to a pointer."
>
C standard ne garantira da postoji integer tip podatka koji je dovoljno velik
da bez gubitka informacije primi vrijednost nekog pointera. Posljedicno, ako
takav tip ne postoji, onda je i pretvaranje integera u pointer besmisleno.
mimix
> Konkretno, kad unutar foo() napravis bar=12, promijenit ce se b; nece referenca
> pokazivat na neku drugu varijablu.
Ne zaboravi napomenuti kako je call-by-reference u C++-u loše izveden
(ili drukčiji ne može ni biti?) jer iz poziva funkcije nije moguće ustanoviti
prenosi li se referenca na vrijednost ili sama vrijednosti.
>
> Inace, ako si upoznat sa UNIX filesystemom:
Uvijek sam se pitao što je hard-link.
Ivan Popovski
> C standard ne garantira da postoji integer tip podatka koji je dovoljno velik
> da bez gubitka informacije primi vrijednost nekog pointera. Posljedicno, ako
> takav tip ne postoji, onda je i pretvaranje integera u pointer besmisleno.
Vis ti to, a recimo na amd64 adresa ima 48 bita, sto je jos jedan zanimljivi
slucaj posto nisu svi pointeri valjani. Nisam siguran na koji nacin se odredjuje
valjanost, pa necu bubnuti maskiranjem prvih 48 bita. Zna netko?
P.S. Jel bi te mogao zamoliti da ANSI C standard stavis negdje na web da ga mogu
skinuti, jer sam ga prije par godina zagubio, a takve stvari uvijek dobro dodju?
Goran Mitrovic
wrote:
>On 2010-08-10, Zeljko Vrba <mordor...@fly.srk.fer.hr> wrote:
>> C standard ne garantira da postoji integer tip podatka koji je dovoljno velik
>> da bez gubitka informacije primi vrijednost nekog pointera. Posljedicno, ako
>> takav tip ne postoji, onda je i pretvaranje integera u pointer besmisleno.
>Vis ti to, a recimo na amd64 adresa ima 48 bita, sto je jos jedan zanimljivi
>slucaj posto nisu svi pointeri valjani. Nisam siguran na koji nacin se odredjuje
>valjanost, pa necu bubnuti maskiranjem prvih 48 bita. Zna netko?
Adrese koje procesor ima prema van nisu isto ono sto vidis unutar procesa.
Zeljko Vrba
> On 2010-08-10, Zeljko Vrba <mordor...@fly.srk.fer.hr> wrote:
>> C standard ne garantira da postoji integer tip podatka koji je dovoljno velik
>> da bez gubitka informacije primi vrijednost nekog pointera. Posljedicno, ako
>> takav tip ne postoji, onda je i pretvaranje integera u pointer besmisleno.
>
> Vis ti to, a recimo na amd64 adresa ima 48 bita, sto je jos jedan zanimljivi
> slucaj posto nisu svi pointeri valjani. Nisam siguran na koji nacin se odredjuje
> valjanost, pa necu bubnuti maskiranjem prvih 48 bita. Zna netko?
>
sign ekstenzijom 48-bitne vrijednosti u bitovima 0-47. Drugim rijecima, bitovi
48-63 moraju imati istu vrijednost kao i bit 47.
>
> P.S. Jel bi te mogao zamoliti da ANSI C standard stavis negdje na web da ga mogu
> skinuti, jer sam ga prije par godina zagubio, a takve stvari uvijek dobro dodju?
>
Nja, to je ilegalno ;) Ali draftovi su javno dostupni.
Ivan Popovski
On 2010-08-10, Goran Mitrovic <gm...@inet.hr> wrote:
>
> Adrese koje procesor ima prema van nisu isto ono sto vidis unutar procesa.
Ak pricas o virtualnoj memoriji, pa to je klasika. Svaki proces ima svoj adresni
prostor cije adrese se (pagingom ili segmentacijom koja se bas ne koristi)
translatiraju u fizicke adrese. Za x86 su u igri bile one tablice, ali posto
nemam toliko iskustva, moze li mi reci ili dati link na kojoj razini i gdje se
gleda dal je 48 bitna adresa ispravna (amd64) i tko moze generirati
takvu adresu (pretpostavljam da je dosta toga na mmu pa me zanima)?
Dakle ovo sto Vrba prica o kanonskim i nekanonskim adresama.
Hvala
Cuj zanima me jos neke stvari oko sheranja stranica izmedju vise procesa
(pogotovo MAP_SHARED od mmapa), pa ak imas materijala ili si raspolozen,
samo pisi :-P
Ivan Popovski
> Postoji tzv. kanonski oblik pointera, sto znaci da se bitovi 48-63 popunjavaju
> sign ekstenzijom 48-bitne vrijednosti u bitovima 0-47. Drugim rijecima, bitovi
> 48-63 moraju imati istu vrijednost kao i bit 47.
Zanimljivo, bas gledam ovaj nekanonski pointer dize general prot fault.
> Nja, to je ilegalno ;) Ali draftovi su javno dostupni.
Ma budem ga vec negdje nasao :-P
Screamin Lord Byron
>> Ne, ne i ne. Glavna razlika je to što se velika većina onoga što u C-u
>> može prouzročiti UB u Javi riješeno u samom jeziku, odnosno kod
>> kompajliranja, a ne u runtimeu.
>>
> Nesto je, ali ne sve. Recimo, SML ima reference (koje su immutable! - jednom
> se postavi i zauvijek pokazuje na svoj objekt) i tamo su SVI problemi koji mogu
> dovesti do UB rijeseni u jeziku. Tamo je takvo sto opravdano zvati
> referencama.
Jedini razlog zašto se loši castovi ne mogu detektirati u Javi je
polimorfizam.
Al OK, složili smo se da ni referenca nije najbolji naziv.
> U Javi se ipak u run-timeu detektira null pointer exception i bad cast (ili
> kako se vec zove) exception. A bad cast je upravo ekvivalentno primjeru kad se
> u C-u char* casta na proizvoljni tip.
Dobro, ali nije baš jer u Javi ne možeš castati u proizvoljni tip, samo
u kompatibilni. Exception se može dogoditi samo kod downcastanja (koje
je uvijek eksplicitno).
class Foo {}
class Bar extends Foo {}
class Baz {}
Foo foo = new Foo();
Bar bar = new Bar();
Baz baz = new Baz();
Foo f1 = bar; // može (implicitni upcast)
// jer je svaki Bar Foo
Bar b1 = foo; // ne može implicitno
Bar b2 = (Bar) foo; // može (ali u ovom primjeru je ClassCastException)
// kompajler nema pojma hoće li foo pokazivati
// na instancu klase Bar u runtimeu
Foo f2 = (Foo) baz; // nema šanse, jer nisu u istoj hijerarhiji
// odnosno tipovi nisu kompatibilni
>> Čak da vraća referencu na neki objekt inicijaliziran u objektu klase
>> Test1, ta referenca *nije komponenta tog objekta*. Komponenta tog
>>
> Sto onda *jesu* komponenta objekta Test1 ako ne reference na a, b i c?
Ma.. Krivo sam napisao, ali mislim da znaš na što sam mislio. :)
Ta referenca je komponenta tog objekta na sličan način kao što je
vrijednost nekog inta u structu komponenta tog structa, ali nije o tome
bilo riječ. Bilo je riječ o pointeru na "sredinu" objekta. U Javi bi to
bio pointer na referencu a, b ili c (da takvo što postoji).
Smola
> > Ti si ocito navikao na striktnu terminologiju vezanu za C++, zar ne?
>
> Mišljenja sam da te stvari moraju biti precizno definirane. I jesu. To
> se ne odnosi samo na C++, već na programske jezike općenito i na ono što
> se zove evaluation strategy.
Ti si ko Eksim koji ima 100 naziva za razlicite vrste snijega i govori
nama da mi to sto pada zimi nije snijeg. :)
--
ako u kavi ostanu grumeni, promijesajte ponovo
dorijan
"rai" <m...@privacy.net> wrote in message
news:q0ga56pubhvagg9be...@4ax.com...
> Pozdrav grupama!
>
> Razmiąljam da upiąem Java edukaciju na TVZ-u:
> http://netakademija.tvz.hr/java/nastava-i-plan/
>
>
> ...pa me zanimaju neke stvari, pogotovo iskustva polaznika. Da li je
> to vrijedno uloľenih novaca i da li su instruktori kvalitetni? Koliko
> vidim, grupa koju bih pohađao pohađao poučava Marijan Matić, dipl.
> ing. rač., SCJP. Profil predavača sugerira da se radi o iskusnom
> programeru i predavaču, no, s obzirom da investiram vlastiti novac,
> ipak me zanimaju iskustva polaznika, ali i studenata kojima Marijan
> predaje.
>
> Iako mi baą ne odgovara lokacija, TVZ-ova ponuda mi se čini
> zanimljivom prije svega zato ąto ima umjeren ritam (2x tjedno) pa sam
> stekao dojam da bih tako kvalitetnije usvojio gradivo nego da sve
> odsluąam za nekakvih tjedan dana.
>
> Hvala unaprijed.
meni se ovo cini kao bolja varijanta
http://academicearth.org/courses/programming-methodology
Screamin Lord Byron
> In article <i3h9ci$3u6$1...@news.metronet.hr>, sc...@min.dot says...
>
>>> Ti si ocito navikao na striktnu terminologiju vezanu za C++, zar ne?
>>
>> Mišljenja sam da te stvari moraju biti precizno definirane. I jesu. To
>> se ne odnosi samo na C++, već na programske jezike općenito i na ono što
>> se zove evaluation strategy.
>
> Ti si ko Eksim koji ima 100 naziva za razlicite vrste snijega i govori
> nama da mi to sto pada zimi nije snijeg. :)
To uopće nije točno! (to da Eskimi imaju 100 riječi za vrste snijega)
:)
Matko
http://webcast.berkeley.edu/course_details_new.php?seriesid=2008-D-26332&semesterid=2008-D
Pozdrav!
Matko
rai
>> Znači pričaš o Marijanu... dobro, ovo mi baš i nije utješno, ali...
>Da. Gle, čovjek se stvarno trudi i zna, jedino, previše je dopuštao da
>ga se prekida nerelevantnim pitanjima, pa bi se tako često odlutalo u
>neku temu koja nije tema predavanja ili bi se išlo ponavljati staro
>gradivo kada je bilo predviđeno nešto drugo, iako je za ovo drugo
>zaslužna grupa koja se nije bog zna što trudila.
Da... to je manjak iskustva koje je valjda stekao u međuvremenu.
>Nije sad da zastupam
>tiraniju, ali bilo bi bolje da je bio malo stroži po tom pitanju. Nu, to
>je samo moje mišljenje. Inače, moguće ga je uvijek bilo cimnuti i
>mailom, na koji bi uvijek odgovorio.
E, ovo je vrlo važno :)
>> Ako se ne
>> varam negdje sam pročitao da drži vježbe na TVZ-u pa mi je zato malo
>> čudno da nema toliko iskustva, ali možda se je malo istrenirao do
>> sada.
>A moguće. Čak ne mislim da je to stvar njegovog iskustva kao predavača,
>više stvar zrelosti samog tečaja. Kao što rekoh, ja sam bio u jednoj od
>prvih grupa. Valjda su u međuvremenu naučili nekog vraga.
Ja se iskreno nadam. Ukoliko se odlučim (a morat ću vrlo uskoro), ne
bih baš volio biti u lošoj grupi :)
rai
>Možda će ti pomoći i ova predavanja:
>http://webcast.berkeley.edu/course_details_new.php?seriesid=2008-D-26332&semesterid=2008-D
Oh da, itekako hoće! :)
Puno hvala za ovo! Tek sam na ovoj grupi saznao da se ovakve korisne
stvari mogu naći na netu, a ja se bezveze patio tražeći samo video
mentore... :) Ajde, oni su bolji s te strane što su baš namjenjeni za
samostalno učenje, ali u nedostatku istih je i ovo stvarno odlično :)
Hvala puno! :)
rai
>meni se ovo cini kao bolja varijanta
>http://academicearth.org/courses/programming-methodology
Fenomenalno! Odlično! Pojma nisam imao da se fakultetska predavanja
mogu naći na netu, ovo je stvarno vrlo korisna informacija! I to ne
samo za ovo, našao sam si tu još zanimljivih onak za svoju dušu, npr.
onaj set predavanja o operacijskim sustavima :)
Hvala puno za ovo! :)
Davorin Vlahovic
http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/
http://see.stanford.edu/SEE/Courses.aspx
http://www.youtube.com/ucberkeley
http://webcast.berkeley.edu/
http://www.youtube.com/user/nptelhrd
http://www.youtube.com/user/unswelearning
http://ocw.nd.edu/
Takodjer:
http://www.khanacademy.org/
http://www.reddit.com/r/carlhprogramming/
--
Some men see things as they are and say: Why?
I dream things that never were and say: Why not?
-- Tatsuya Ishida
Smola
says...
> Tek sam na ovoj grupi saznao da se ovakve korisne
> stvari mogu naći na netu,
Ma samo se drzi useneta kad zapne. Vecinu svog znanja sam pokupio s
ovakvih grupa.
rai
>[Mon, 16 Aug 2010 19:21:18 +0200] rai je napisao/la:
>> Fenomenalno! Odlično! Pojma nisam imao da se fakultetska predavanja
>> mogu naći na netu, ovo je stvarno vrlo korisna informacija! I to ne
>> samo za ovo, našao sam si tu još zanimljivih onak za svoju dušu, npr.
>> onaj set predavanja o operacijskim sustavima :)
>> Hvala puno za ovo! :)
>http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/
>http://see.stanford.edu/SEE/Courses.aspx
>http://www.youtube.com/ucberkeley
>http://webcast.berkeley.edu/
>http://www.youtube.com/user/nptelhrd
>http://www.youtube.com/user/unswelearning
>http://ocw.nd.edu/
>Takodjer:
>http://www.khanacademy.org/
>http://www.reddit.com/r/carlhprogramming/
Lijepo, lijepo... vrlo zahvalan za ovo :)
Davorin Vlahovic
Nema na cemu, i drugi put.
Ivica Loncar
On 2010-08-04, rai <m...@privacy.net> wrote:
> Nego, da samo spomenem zašto uopće planiram upisati tu edukaciju.
> Radim na poslu kao sistemaš, a glavni posao mi je administracija
> IBM-ovog Websphere Application Servera (WAS-a). Dobro radim posao,
> snalazim se u svemu tome, ali osjećam da mi je veliki nedostatak
> znanja iz Java programiranja te da bih puno bolje radio posao da
> naučim nešto o Javi. Naime, najvažniji WAS logovi su mi JVM logovi. A
> mislim da bih puno brže i kvalitetnije čitao JVM logove da naučim
> nešto o Javi, a i usput bih si malo popravio reference te proširio
> mogućnosti ukoliko mi se jednog dana pruži prilika za nekakvo
> napredovanje ili sl.
Ne trosi vrijeme na taj TVZ tecaj.
Uzmi knjige u ruke, eksperimentiraj i druzi se s ljudima koji imaju znanja
koja zelis steci.
--
Ivica Loncar