Vlákno názorů k článku Programovací jazyk Lua vestavěný do aplikací od backup - uz v nekolika po soube jdoucich pokracovanich se...
-
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".
ČLÁNKY DO MAILU