Názory k článku Programovací jazyk Lua vestavěný do aplikací
-
1) ... můj problém to ještě neřeší. Já bych potřeboval vytvořit sadu funkcí ve skriptu, které bych volal v rámci C++ kódu. Umí to Lua (nebo to jen zase nogómu)?
2) Otázkou je taky, zda takové volání externího bitekódu / parsování skriptu neužírá výkon. Dejme tomu, že mám nějaké herní objekty (např. sprity), a všechny obsahují funkci update() v jejímž rámci je prováděna aktualizace hodnot struktůry daného objektu tak, aby se oběkt choval požadovaným způsobem. Abych nemusel při každém požadavku nějaké změny v chování daných oběktů zasahovat do zdrojáku aplikace, vyřeším to například tímto způsobem (popisovaným v článku). Je logické že např. u her bude takováto metoda u podobných oběktu volána dost často a velká režie na volání externího kódu by mohla být docela problém.... -
Pavel TišnovskýZlatý podporovatel1) pokud dokážeš získat ukazatel na tu funkci, tak není problém. Ten by nastal jen u nestatických metod, ty mají v hlavičce jeden parametr navíc, navíc mám dojem, že na tyto funkce nejde získat ukazatel. Asi Ti pomůže http://csl.sublevel3.org/lua/, ty příklady samozřejmě chodí i ve VC, BCC apod. Pokud by nevyhovoval "céčkový základ" Lua, lze použít různé C++ wrappery, například http://www.steve.org.uk/Software/lua-c++/. Ještě se o tom zmíním příště.
2) pokud se zdroják nejdříve přeloží do bajtkódu, odpadá část pro jeho parsing a překlad, nehledě na to, že bajtkód je menší a načítá se rychleji (i když u zdrojáků < 10 mega se to asi nepozná :-). Volání Lua2c nebo Lua2c++ něco stojí (nepoužívá se standardní stack frame), ale většinou to není nijak hrozné, záleží samozřejmě na způsobu použití. -
hyperion (neregistrovaný)To bude spis problemem toho samotneho bindingu ne? ted se divam, ze je to ve verzi 0.9, ani to nema domaci stranku, takze z ceho lze predpokladat, ze ten binding delal nekdo alespon trosku pri smyslech? Napriklad takove wxLua je naopak docela jednoduche (v porovnani s pure C++ resenim), kdyz si clovek zvykne na wx-like veci, jako je propojovani udalosti s jejich cili (handlery).
-
Jo, teď jsem se na to taky díval. Ale podle mě se Fox na takovýhle věci zrovna dvakrát moc nehodí. Už jen třeba kvůli proměnlivému počtu a typu parametrů konstruktorů jednotlivých objektů, nutnosti udržovat specialní tabulku pro mapování událostí, a pod. Nehledě na to, že většina takových "transportů" Fox Toolkitu do jiných jazyků vůbec nebere v potaz fakt, že stěžejní vlastnosti na níž staví FoxToolkit je C++ polymorfizmuz, a vznikne z toho většinou nepouživatelný nebo těžkopádný zkamenělý paskvil... Podobně jak tomu je u portu Foxky do TCL. Jedním slovem děs :(
-
backup (neregistrovaný)ja se priznam, ze nejsem informatik, takze se na podobne problemy dokazu divat jen prakticky z povzdali. Zatim jsem pochytil nasledujici:
- kombinace skriptovaci jazyk + C jde jednoduseji nez skriptovaci jazyk + C++. To jsem vycetl napr. u swigu - tam myslim rikaji v manualu, co jde jednoduse a co dokonce vubec nejde. Myslim, ze tam psali, ze to je prave tou C++
- v diskuzich ( a ze uz jich bylo na netu miliony) o tom, jestli ma byt nejaka GUI v C nebo C++ se najde vzdy argument, ze C implementace my vyhodu v jednodussim spojeni s nejakym skriptovacim jazykem (typicke srovnani gtk/Qt)
Dovedu si predstavit, ze kdyz mam nejaky hotovy toolkit, ktery ma nejake mechanismy (napr. to mapovani udalosti), tak ze se musim poprat i s toto problematikou - ale ve srovnani C/C++ vychazim z toho, ze i C implementace nejakeho toolkitu by nejak mapovala udalosti - te praci se tedy nevyhnu.
Ale jak napsal i vas predrecnik, ten nazor akceptuji, ze ta slozitost u te fxlua me zmatla tim smerem, ze jsem ji kompletne pricital jen te C++.
Rad bych, kdyby to mohl nekdo fundovane vysvetlit. -
Někde jsem četl, že existují tři věci které mohou zrujnovat muže : ženy, hazard a bezmezná důvěra odborníkům :) Proto nevěřte žádným podobným "fundovaným" řečem - mě osobně ještě v žádné diskuzi (bez ohledu na to, která jazyky byly srovnávány) nikdo nepodal přesvědčivý důkaz o tom, že by upřednostňování apriory nějakého konkrétního jazyku přinášelo nějaké velké výhody. Kolik programátárů tolik pohledu na danou věc a žádné oběktivní hledisko v tomto směru neexistuje. Pokud Vám vyhovuje čisté C, tak v něm pracujte a vzdělávejte se v něm. "Fundovanější" radu neznám a velmi pochybuji o tom, že Vám ji někdo dá...
1) Nevěřím tomu, že by řešení C a script bylo výhodnější než C++ a script. Možná pouze z toho hlediska, že pokud se budete snažit přenést takové řešení do prostředí C++, pravděpodobně to nebude tak obtížné jako v opačném případě. Přicházíte však o možnosti a abstrakce, které vám nabýzí C++ díky třídám a šablonám (nebo je musíte složitě nahrazovat - je-li to vůbec možné). Jinak si myslým, že obě řešení by měla být relativně rovnocenná - záleží na konkrétním projektu a programátorovy (programátorech). v případě Swinngu nevím, ale tam možná omezení můžou být daná Javou.
2) Viz úvod a bod 1. Jinak porovnávání Qt s Gtk je hloupost (ale oblíbená, to je fakt). To už možná QT s Fox Toolkitem. -
anonymní
Přicházíte však o možnosti a abstrakce, které vám nabýzí C++ díky třídám a šablonám
Naštěstí tím nepřichází o možnosti a abstrakce, které C++ nikdy nenabízelo, například dynamické objektové systémy, kvalitní koncept funkce (plný lexikální scoping) a podobně.
(nebo je musíte složitě nahrazovat - je-li to vůbec možné).
Leckdy se dá nahrazovat jednoduše, není třeba nahrazovat složitě. Kromě toho se mi zdá, jako byste měl dojem, že C++ templates jsou snad jakýmsi nedostižným vrcholkem všech makrosystémů, který je zapotřebí kopírovat, když je složitý makrosystém zapotřebí.
Můj názor je prostý: šroubovat šroubovákem a zatloukat kladívkem. C++ jsou bohužel kombinačky. Ano, dají se s nimi žvýkat matky a pižlat dráty, ale chce to medaili za hrdinství. :]
-
Pavel TišnovskýZlatý podporovatelMam dojem, ze ta prvni veta je ze skvele knizky "Programatorske poklesky" :-)
-
Pavel TišnovskýZlatý podporovatelnj. uz ji myslim nepretiskli :-( Dnes leti spise tituly typu "Word za 3 dny" atd. :-)
-
limit_false (neregistrovaný)Zrovna polymorfismus C++ bych jako problem nevidel. Napr. c++ wrapper vygenerovany swig-em zavola metodu a vtable se postara, aby byla zavolana spravna "verze".
Vetsi problem jsou treba sablony nebo pretizene metody, ktere nejdou rozlisit pri volani ze skriptovaciho jazyka (napr. se lisi typem argumentu, ktery je mapovan ve skriptovacim jazyku na tentyz typ).
Fox toolkit neznam, ale napr. pro Qt je navic potreba se vyporadat s kodem vygenerovanym pres meta-object compiler, ktery spolu s preprocesorem resi prepojovani signalu a slotu ("hack", ktery pridava reflexi, ale psat wrapper bych pro to nechtel ;-)) -
Nějak tak jsem to myslel - snažil jsem se to říci co nejobecněji (a na šablony jsem absolutně zapoměl - pravda), jsem prostě lenoch :D
Fox Toolkit používá trochu jiný systém pro zpětná volání - zprávy (QT používá systém slot-signal). Jinak je to podobné. Místo rozvíjení potřebných maker v oběktech (i mimo ně) externím programem, je u Foxky využit preprocesor. -
Pavel TišnovskýZlatý podporovatelAd druhy odstavec - toto problem zde opravdu je, na druhou stranu vsak pretizena metoda, ktera pro kazdy typ funguje jinak, je obecne cesta do velmi nepeknych mist :-) Napriklad slusne API by sice mohlo obsahovat metody (popripade konstruktory) metoda(char a), metoda(int a), metoda(long a), ale je dobrym zvykem, ze se ty metody chovaji v ramci moznosti stejne, tj. pri automatickem wrappingu Lua to C++ by melo byt jedno, ktera se zavola (pokud se metody chovaji ruzne, tak by napriklad chudak uzivatel tohoto API musel rozlisovat mezi metoda(42) a metoda(42L), coz je IMHO dosti error-prone).
-
limit_false (neregistrovaný)Ja mel spis na mysli neco jako logMessage(const char*) a logMessage(const std::string&). Obe metody delaji to same, je jedno ktera konverze se pouzije. Zrovna v tomhle jednoduchem pripade vybere swig 'const char*' verzi.
Ve slozitejsich pripadech to nekdy neuhodne (misto toho zahlasi neco jako "don't know which overloaded method to use"), je potreba "dovysvetlit rucne". -
anonymní* The luaopen_* functions (to open libraries) cannot be called directly, like a regular C function. They must be called through Lua, like a Lua function.
* Function lua_open was replaced by lua_newstate to allow the user to set a memory-allocation function. You can use luaL_newstate from the standard library to create a state with a standard allocation function (based on realloc). -
Pavel TišnovskýZlatý podporovatellua_open() lze normalne zavolat, nebot je v hlavickovem souboru zadefinovana jako makro, ktere vola luaL_newstate. Volani lua_newstate() skutecne ma smysl pouze tehdy, kdyz potrebujeme pamet alokovat jinym zpusobem, nez to delaji klasicke libc funkce.
luaopen_* lze samozrejme nahradit luaL_openlibs(). To varovani je napsane proto, ze funkce s parametry se skutecne museji volat pres lua_call(), protoze zpusob ulozeni parametru na zasobniku je v tomto pripade odlisny od std. cecka - opacne poradi + je pridany pocet parametru. -
Pavel TišnovskýZlatý podporovatelV kazdem pripade ale mate pravdu v tom, ze propriste budu presne specifikovat verzi Lua (mezi 5.0.x a 5.1 jsou zmeny v API) a taktez budu pouzivat nejnovejsi API, tj. to z 5.1, aby zbytecne nedochazelo k rozporum napriklad pri cteni aktualni dokumentace. Diky za upozorneni!
-
anonymnídopsat si do aplikace, kterou scriptujete v lua, debugger, by nemusel byt takovy problem. globals jsou v tabuli LUA_GLOBALSINDEX -- staci iterovat, hook nastavite pres lua_sethook a informace o fci ziskate pres lua_getinfo; viz manual: http://www.lua.org/manual/5.1/manual.html
-
Pavel TišnovskýZlatý podporovatelZdravím,
těch debugerů je více, některé používají standardní debuging interface interpertru, jiné vyžadují úpravu zdrojáků před překladem.
z non-free je pěkný http://www.unknownworlds.com/decoda (debuger s GUI, vlastně celé IDE, ale jak říkám, not-free, non-cost free)
potom je zde cmd. line debugger http://luaforge.net/projects/clidebugger/
nad kterym je postaven http://lua-users.org/wiki/SciteDebug
taktez lze pouzit http://www.keplerproject.org/remdebug/, ktery je mimochodem i soucasti LuaEclipse (ale pro mnoho programatoru to muze byt kanon na vrabce :-)
Osobne si ale myslim (ale je to dano tim, ze me aplikace v Lua maji max. par tisic radku, zadne slozitosti), ze nejjednodussi je primo vyuzit debug interface a pres nej si vytahat vsechny relevantni informace a ty logovat (pokud tedy neni zapotrebi interaktivni debuging, potom je lepsi sahnout po hotovem nastroji nebo si nad debug interfacem udelat nejake callbacky).
V podstate problem muze nastat v pripade, ze se ma soubezne ladit jak ceckovy kod, tak i Lua kod, aby prechod mezi obema castmi byl co nejjednodussi - teoreticky SciteDebug by to resit mohl, ale nemam ho vyzkouseny. Jinak -
anonymní
taktez lze pouzit http://www.keplerproject.org/remdebug/, ktery je mimochodem i soucasti LuaEclipse (ale pro mnoho programatoru to muze byt kanon na vrabce :-)
Remdebug je moc pěkná věc, ale LuaEclipse...skoro mi přijde, že používat Eclipse na programování v Lua je takový docela slušný váhový nepoměr. :-] -
anonymníAhoj,
kdyz to chci zkompilovat tak to hlasi toto:
tom@tom-desktop:~/lua$ gcc -o main main.c /usr/lib/liblua50.a
/tmp/ccaYP80k.o: In function `main':
main.c:(.text+0x44): undefined reference to `luaopen_base'
main.c:(.text+0x58): undefined reference to `luaL_dostring'
collect2: ld returned 1 exit status
nevite co s tim prosim? ani hodina googleni nepomohla, tak se ptam tady.
dekuju -
Blaf (neregistrovaný)
Zaregistrované funkce se nedají volat z coroutin.
function main()
print(getsomething())
coroutine.resume(coreroutine)
end
coreroutine = coroutine.create(
function()
repeat
print(getsomething())
coroutine.yield(mask)
until 1 == 2
end
)
Pokud getsomething() je zaregistrovaná funkce vracející třeba 15, pak výše uvedený kód vydá něco jako
15
function: 0x7f31c0
Nevíte někdo, jak získat z coroutiny hodnotu vrácenou zaregistrovanou C funkcí?
ČLÁNKY DO MAILU