Vlákno názorů k článku Vývoj PHP 6 od Jakub Hegenbart - The name "goto" is misleading, and often associated...
-
The name "goto" is misleading, and often associated with BAD THINGS(tm). Because our proposed solution is not a real GOTO construct, we will instead reuse the "break" keyword, and extend it with a static label.
No to je gól. :-D Raději tomu budeme říkat jinak, protože to jméno má špatnou pověst, přestože bychom tomu dali úplně stejnou funkčnost, i kdyby se to mělo pořád jmenovat GOTO. No to je mi logika. :-D
-
Pavel TišnovskýZlatý podporovatelZalezi na tom, jak stukturujete program, tj. jak cely problem delite na podproblemy. To, ze je zapotrebi vyskakovat z vice vnorenych cyklu totiz muze znamenat, ze se v jedne procedure/funkci/metode snazite udelat vic veci soucasne a muze byt vyhodnejsi problem rozlozit a treba z jedne smycky volat jednodussi funkci.
Ja vim, "moderni" jazyky maji problemy s predavanim parametru, takze se ten rozklad na podproblemy dela slozite. Je to skoda, protoze napriklad takovy Forth vede prave k systemu programovani "rozdel a panuj" (a tento princip vlastne vedl ke vzniku celeho OOP). -
Bilbo (neregistrovaný)No problem muze byt treba kdyz zpravovavam nejaka tri- ci vice-dimenzionalni data ... to jsou pak min. tri vnorene cykly a nekdy je treba vyskocit o vic ....
Ne vzdy je ucelne drobit to do nejakych podfunkci a cpat tam return ... jednak predavani parametru, jednak nekdy i prehlednost. -
anonymníNekdo ma rad buchty a jiny zase holky.
Takze jen nejak nechapu jaky je rozdil umet se ztratit v 30ti promennych dejme tomu o 2^30 stavech a moznych pruchdech pro optimalizaci vypoctu nad vicerozmernym prostorem nebo v deseti goto a 5ti promennyma s priblizne stejnym poctem moznych pruchodu, az na to, ze vysledny kod v pripade pouziti goto se vleze na vyrazne min stranek a ve finale se v nem lip orientuje. -
Obávám se, že jste to špatně pochopil. Vzhledem k tomu, že vývojáři do jazyka nechtějí dát kompletní GOTO, tak pro tuto konstrukci navrhují jiné jméno. Tím pádem nedojde k tomu, že někdo použije GOTO stejně jako je zvyklý v jiných jazycích a bude se divit, že nefunguje. Dále to nebude svádět psát programy ve stylu Basicu (20 GOTO 10). Pokud by se nakonec použilo kompletně vybavené GOTO (což je vzhledem k probíhajícím debatám docela dobře možné), tak by nejspíš dostalo jméno GOTO. -
Ale pochopil, pochopil... Pár jazyků s podobně ořezaným GOTO jsem už, myslím, viděl, a motivace autorů vždycky byla stejná. Ale protože GOTO i v takovém kontextu je pořád GOTO, nikoho to nenapadlo přejmenovat. Já vždycky myslel, že GOTO je nepodmíněný skok na pojmenované nebo očíslované místo programu mimo rámec strukturování kódu do funkcí a pokud tahle jazyková konstrukce dělá něco jiného, strašně rád se nechám poučit, co vlastně. ;-)
A že to jazykově nesedí, to nevadí? "break blah" - copak to přeruší nějaké "blah"? Já myslel že "goto blah" je sémanticky angličtinářsky správně. Ale dneska máme toho newspeaku hromadu, a kromě toho, co si dělá PHP je mi celkem jedno. Jen z toho trošku "unbellyfeeluju" :-D -
Pavel TišnovskýZlatý podporovatelA i do jazyku, ktere maji pouziti GOTO celkem rozumne omezene (C, Placal) nacpali zli Basicari aspon setjmp() a longjmp() :-)))
Semanticky je to nejhure udelane v Jave, tam aby zakryli, ze break je vlastne GOTO, dokonce umistili label do jine pozice, nez na kterou se skace :-) -
Bilbo (neregistrovaný)No setjmp a longjmp je vic nez pouhe goto, protoze to i ulozi/obnovi stack, cili muzu skakat i nekam uplne mimo aktualni funkci (tedy muzu skakat "vyse" ale uz ne "nize" nebo "napric")... pouzitelne treba nekde pri konstrukci exception handleru nebo podobnych veci (cili streva runtime libraries :o)
-
"rozumne omezene" jo ? Zkuste si s goto - nebo treba i se setjmp a longjmp - implementovat multithreading ... na druhou stranu, dokud je mozne k C linkovat assembler, neni treba kvuli te jedne funkci na prepinani threadu pridavat jazykovy konstrukt (a prepinat thready jednoho typu ve vic nez jedne funkci je blby napad). Navic jak C, tak packal obsahuji inline assember.
-
Pavel TišnovskýZlatý podporovatelPokud je GOTO omezene pouze v ramci jedne funkce/metody (+ dalsi omezeni, ktera se tykaji smycek), tak je implementovano stejnym zpusobem jako smycky, akorat tam jsou misto relativnich kratkych skoku typu "jnc", "jz" apod. short jumpy.
Ja vsak nejsem v zadnem pripade zastancem GOTO a ani breaku pres vice smycek - GOTO jsem nepouzil uz peknou radku let a break pres vice smycek stejne neni v C-cku podporovany a v Jave, kdyz na podobnou konstrukci narazim, pouziju Forthovskou zasadu "rozdel a panuj" :-)
Naproti tomu predcasny vyskok z jedne smycky se pouziva dost casto, protoze to nahrazuje vlozene podminky a slozitejsi testy na zacatku/konci. -
Takze souhlasite, ze goto je pro nektere ucely omezeno prilis a implementace setjmp a longjmp byla nutna ?
Kdyz uz tak mavate tim assemblerem, zkuste se podivat, co vam to vase Forthovske "rozdel a panuj" vygeneruje za obludnosti na tema predavani argumentu do funkce. Forth je na to delany (snad), ale C proste NE. V C obcas musite obetovat trochu teoreticke cistoty kodu tomu, aby to nebylo line jak mrcha. Docela by me zajimalo, jak si s tim poradi Java JIT ...
Oproti tomu break pres vic smycek nahrazuje houf naprosto zbytecnych testu nasledujicich vnitrni smycku. -
"zkuste se podivat, co vam to vase Forthovske "rozdel a panuj" vygeneruje za obludnosti na tema predavani argumentu do funkce"
...que? Viděl jste Forth aspoň z rychlíku? Kdyby totiž ano, pak bystě těžko něco takového mohl napsat. Režie Forthu na předání parametrů je nulová, režie návratu z funkce (slova) taky. -
Co to ocitovat cele ? zkuste se podivat, co vam to vase Forthovske "rozdel a panuj" vygeneruje za obludnosti na tema predavani argumentu do funkce. Forth je na to delany (snad), ale C proste NE.
Pro pripad ze by vam to nebylo jasne, napisu to jeste jednou: zkuste se podivat, co vam to vase Forthovske "rozdel a panuj" vygeneruje v ostatnich jazycich (nez je Forth) za obludnosti na tema predavani argumentu do funkce. Rikal jste, ze ho pouzivate v Jave misto vicenasobneho breaku a mel jsem podezreni, ze by jste ho doporucil i v dalsich jazycich, treba v C misto goto. -
Mate pravdu, to byl Pavel Tišnovský kdo to pouzival ... ale na principu to nic nemeni, proste o Forthu jsem nemluvil.
Bat se zapouzdrani mozna ano, ale zapouzdrovat pokazde, kdyz chcete pouzit dvojity break, ne. Tedy, jak je u optimalizace obvykle, zalezi na dalsich okolnostech - konkretne treba na poctu argumentu. Osobne me sice nenapada pripad, kdy by zapouzdreni bylo rychlejsi, ale verim ze takovy existuje. Krome toho pokud je vnitrni funkce static inline, muzete spolehat na to, ze ji prekladac vlozi zpatky a tim ziskate "cistci" kod za cenu trochu casu pri prekladu (tedy levne). -
Tomu trošku nerozumím. Ten return mě přece vyhodí přesně z toho bloku, který chci vynechat a proto jsem ho zapouzdřil do funkce. Vnější smyčka volající funkci nebude dotčena. V Cčku je trošku problém s absencí lexikálních uzávěrů, hodily by se i anonymní funkce, takže obcházení goro přes návrat ze samostatné funkce může být někdy trošku tricky...hmm, další důvody, proč k psaní větších aplikací nepoužívat jazyk navržený především k psaní Unixů... :-D
Nicméně, právě proto v dnešních jazycích goto je. Myslím si totiž, že snaha za každou cenu obcházet goto v jazyku, který není nijak extra čistý ani v jiných směrech je bláznovství. Co třeba tohle?
http://www.cprogramming.com/tutorial/goto.html
http://www.exim.org/mail-archives/exim-dev/2005-August/msg00003.html
http://youngbloods.org/essays/argument_for_goto.html -
Chtel jsem rict ze kdyz cela ta smycka je jeste v jedne smycce tak se to nula celá nula nula nula mravenec muze nascitat podle hesla stokrat nic umorilo osla.
Ano, Ccko je jazyk jineho typu nez forth a obchazet v nem goto je nesmysl. Pro vetsi aplikace je to jazyk dobry, ale nikoliv vyborny. Bohuzel obecny vyborny jazyk zatim neexistuje - tim myslim, ze zatimco pro nektere projekty je vybornym jazykem Java nebo C++, pro mnohe je stale nejlepsi C i se svymi nevyhodami.
Uvedena situace je snad docasna a lze ji zmenit vylepsenim java JIT a C++ kompileru. -
Pavel TišnovskýZlatý podporovatelO Jave jsem mluvil ja a ne Jakub, takze to pada na mou hlavu :-)
Jak uz jsem psal v prispevku nize, predavani parametru je v TECHTO PRIPADECH reseno i v C-cku primitivne pres registry, ve skutecnosti se totiz pouzije inline funkce a dopad na vykonnost to nema zadny. JIT take pouzije inline funkce, takze se zadne casove ani prostorove narocne predavani parametru nekona.
Jinak cecko preklada na ruzne architektury, u nichs se napriklad takove obludnosti, jako je stack-frame ani nedaji rozume pouzit, takze slozitym predavanim parametru (ala x86) se neda argumentovat. -
Mozna mate takovy prekladac, ale na linuxu na x86 se defaultne (podle defaultniho ABI) vse preklada se zasobnikovou volaci konvenci (a kdyz to prepnete (mregparm), neprilinkujete libc). x86 sice neni architektura jedina, ale je nejrozsirenejsi. Jak jsem rikal, pokud je funkce static inline, muzete dosahnout toho ze ji prekladac presune zpatky - ale spolehnout se na to nemuzete.
-
Pavel TišnovskýZlatý podporovatelPri prekladu napriklad GCCckem s parametrem -O3 nebo (pro psavce) -finline-functions se i ve standardnim cecku (tedy zadna pluska ani GNU rozsireni) budou inline funkce hledat a take tak prekladat. Samozrejme, ze bez optimalizaci se na to prekladac vyflakne, ale potom stoji za uvazeni, proc vlastne to cecko pouzivat (flame), kdyz to i v te pitome Jave s JITem pobezi rychleji (a to za me JITko dela i takove "malickosti", jako kontrolu mezi poli apod.).
Ja jsem byl po dlouhou dobu zastancem cecka, alespon co se tyce programu s naroky na rychlost, ale posledni verze JIT ("server" verze) me presvedcuji o tom, ze preklad s analyzou behu programu je pro mnoho veci vyhodnejsi - holt se az za behu zjisti veci, ktere prekladac pri kompilaci "statickeho" zdrojaku nemuze vedet :-) -
Pravda, i bez static muze prekladac funkci inlineovat (a nechat jednu neinlineovanou kopii). Nejak doufam, ze to v tom pripade dela jen pro mensi funkce (aby neplytval mistem), ale netestoval jsem.
Posledni CVS verzi Sun Javy jsem netestoval, ale IMHO stale plati, ze zatimco po delsim behu uz je program zoptimalizovany (kontroly mezi poli vyhazene na zaklade zjisteni, ze k prekroceni mezi nedojde a podobne), pri spousteni noveho kodu je porad rezie Javy dost vyrazna. Ano, pro mnoho velkych projektu to nevadi, protoze se to v celkove dobe behu ztrati ... ale obecne to neplati. -
Pavel TišnovskýZlatý podporovatelOn tu neinlineovanou kopii ponechat nemusi, protoze z kontextu vi, ze se ta funkce nikde jinde nepouzije (to samozrejme plati pouze pro funkce deklarovane jako inline nebo static). I funkce nadeklarovane "inline", ktere se prekladaci nelibi, se nemusi linkovat primo do kodu - to ostatne rika i norma. Vzhledem k tomu, ze se mi zatim darilo jako inline funkce delat opravdu kratke kody (klasicke jsou settery a gettery), tak to GCCcko vzdycky prelozilo tak, jak jsem potreboval.
Ja jsem JITko testoval na verzich 1.4 a 1.5, ta jedna-petka mela aplikovane nejake bug-fixy, ale urcite to neni nejnovejsi vec, spis tak o rok pozadu. Ano, ta rezie je opravdu velka, takze pro mensi utility, ktere se casto pousti, se to nehodi (to je jedna z veci, ktera mi na cele platforme Javy hodne vadi). Na druhou stranu napriklad TomCat nebo JBoss spousti Javovske servlety rychleji, nez Apache Perlovske skripty :-).
BTW, vzdycky jsem povazoval kod vylezly z cecka za "neprenositelny" v tom smyslu, ze cecko je vlastne urceno k tomu, aby se mezi platformami prenasely zdrojaky a ne binarky, u kterych se preklad provadi tak, ze se zvoli "nejmensi spolecny jmenovatel" vsech cilovych platforem. Protoze preklad binarky pro predem nezname platformy prakticky vzdy vyprodukuje neefektivni kod, napriklad dnes je porad popularni preklad pro i386, dnesni procesory toho umi podstatne vice (MMX, SSE2, pipelining atd.). Takze distribuce binarky, pokud to tedy neni osetreno nejakymi testy a vyberem spravne vetve kodu podle procesoru (objemova neefektivita), to cecko strasnym zpusobem degraduje, nehlede na to, ze nektere veci nejdou na i386 vubec napsat (napriklad multiprocessing ma podporu v jedne instrukci az i486, ale ten se stejne na platforme PC moc neujal). Z toho vyplyva, ze duraz na efektivitu prelozeneho kodu je na uzivateli (resp. jeho spravci), ktery by mel preklad provest tak, aby to bezelo co nejrychleji (-O3, -march atd. atd.).
Nebo se na celou efektivitu muzeme vyflaknout a pouzivat moderni i lety osvedcene dynamicke jazyky, ve kterych se aplikace pisou mnohem rychleji nez v cecku a nehrozi pritom to, ze jsem zrovna nedavno objevil v jedne bezne prodavane aplikaci za cca 120 000 Kc dosti usmevny memory leak. -
"zkuste se podivat, co vam to vase Forthovske "rozdel a panuj" vygeneruje za obludnosti na tema predavani argumentu do funkce"
...que? Viděl jste Forth aspoň z rychlíku? Kdyby totiž ano, pak bystě těžko něco takového mohl napsat. Režie Forthu na předání parametrů je nulová, režie návratu z funkce (slova) taky. -
Pavel TišnovskýZlatý podporovatel
Jasne, goto je v C-cku omezene a je to tak dobre, o tom se snad nehadame :-) Implementace v assembleru je velmi podobna smyckam a podminkam, takze zadne "prasarny" navic se nekonaji, v tomto by taky nemel byt problem.
V C-cku je predavani parametru v _TECHTO_PRIPADECH_ stejne jako ve Forthu, alespon u slusnych prekladacu. Jde o to, ze ty volane procedury/funkce jsou v 99% tak primitivni, ze se stejne vsechno preda v registrech a vlastne o predavani nemuze byt rec, protoze se prelozi jako inline.
Opravdu jde pouze o cistotu kodu, vsechnu spinavou praci nechame na prekladaci ci JIT.
Kdyz jsem u toho JIT: zrovna pred cca dvema tydny jsem neco podobneho zkousel kvuli porovnani rychlosti Javovskeho a C-ckovskeho kodu. Vypadalo to asi takto:
for (int j=0; j!=10000; j++) for (int i=0; i!=10000; i++) for (int k=0; k!=10000; k++) volejfunkci(i,j,k); // sorry za ty !=, maji tam byt mensitka, ale Root to zdrbeC bez inline funkci bylo samozrejme neskutecne pomale, ovsem s inline funkcemi se rychlost ceckoveho a Javovskeho kodu uplne srovnala (rozdily cca 5%), takze JIT uz automaticky inline funkce rozezna, a to bez jakychkoli modifikatoru (zadne final ani static).
ČLÁNKY DO MAILU