Sprievodca pre portovanie aplikácií z GTK+ na Qt

Vývojári LXDE ponúkli nedávno správcu súborov PCManFM aj ako port v Qt. Qt verzia bude koexistovať s pôvodnou verziou GTK+. Na základe skúseností z portovania zverejnili na wiki LXDE počiatočnú verziu sprievodcu pre portovanie aplikácií z GTK+ na Qt. Vývojári LXDE dúfajú, že záujemcovia pomôžu túto wiki stránku rozširovať a spresňovať.

25.4.2013 22:08 | Andrtalec | Zajímavý článek

Komentáře

[chrono]

Sú programy, ktoré má zmysel portovať, ale pochybujem, že medzi ne patrí správca súborov (pretože urobiť to celé znovu bude asi rýchlejšie).

[Jardík]

+1, navíc to bude plný marshallování z glibu do qt. I blbé převody z utf8 do utf16 (a s tím spojené alokace) budou zdržovat a stane se z toho pomalá kráva.

[pavlix]

Uff, to jsem netušil, že Qt používá utf-16.

[pavlix]

http://programmers.stackexchange.com/questions/102205/should-utf-16-be-considered-harmful

[Luboš Doležel (Doli)]

Podle mě používají spíš UTF-32.

[__dark__]

UTF-16, viz http://qt-project.org/doc/qt-4.8/qstring.html

[David Šmíd]

Původně asi použili UTF-16 ve smyslu UCS-2 (tj. zaručená velikost znaku 2), což bylo v té době pro vnitřní reprezentaci asi ideální řešení (stejnou cestu zvolil Apple i Microsoft), jenže pozdější revize Unicodu a předefinování UCS-2 jako UTF-16 (tj. proměnlivá velikost znaku) jim to celé nabouralo.

Jeden surrogate pár je tak reprezentován dvěma QChary.

 

---

[Luboš Doležel (Doli)]

Aha, neni pak blbý, že pomocí jednoho QChar nemůžu vyjádřit všechny znaky?

[Rezza]

Na druhou stranu pisou - nejsme politicti fasisti a proste proc nevolat hotovou glibovou knihovnu, Ano, boli to, delal jsem to, ale..

[pavlix]

Ono by bylo hezké, kdyby ty věci mohly nějakým způsobem konvergovat. Ale pro Qt je náboženství C++ a pro GLib je náboženství čisté C. Takže je celkem logické, že z Qt se dá GLib používat lépe než naopak, ale tím pádem to platí pro všechna prostřední, nejen Qt.

[Rezza]

Tohle neberu, ale pak z te druhe strany jsou ti fanatici, co nepouziji i framework co vznikl na GLibem jen proto, ze aktualni implementace serveru je v Qt - komunikuje pres DBus .

[pavlix]

Ač mám GLib pořád mnohem radši než Qt (což neznamená, že ho mám rád), už jenom proto, že je to ještě relativně tenká knihovna bez GUI balastu, nepovažuju to nutně za fanatismus. Ne všechny tyhle backendy či frameworky nad GLibem jsou v perfektní stavu a ne u všech je perfektní odezva na hlášení chyb, takže dokážu pochopit, že se dotyční obávají toho, že se budou muset ještě učit C a GLib, aby si to mohli případně sami opravit.

Nevím jak KDE, ale jednotlivci z gnomácké komunity někdy vykřikují taková pochybná hesla, naposled ten Vinzent Untz na FOSDEMu, že kdybych ho měl brát vážně, tak už o nic gnomáckého v životě nezavadím.

[little.owl]

Ač mám GLib pořád mnohem radši než Qt (což neznamená, že ho mám rád), už jenom proto, že je to ještě relativně tenká knihovna bez GUI balastu,

+1

A to mam rad C++, ale Qt ... radsi i knihovny jako Boost, kde to jde a ma smysl ...

Faktem je, ze snaha ucinit kod pouzitelny i v jinych jazycich napsanych v C sla vyrazne na ukor pouzitelnosti a jednoduchosti v samotnem C, ale pristup v GLib, zejmena GObject Introspection, se mi celkem zamlouva.

Vinzent Untz na FOSDEMu,

U nej jsem opravdu nevedel, jestli si z dela prdel, mysli to opravdu vazne nebo je jen zhuleny.

[Rezza]

GUI balast uz neni ani u Qt pravda - je to samostatny modul v Qt 5. Dokonce jednu dobu to i vypadalo, ze to ma za sebou :)

[Rezza]

Na velikosti RPM glib2 a qt5-qtbase skoro to same .

[little.owl]

Nepodival jsem se, ale nechcete snad tvrdit, ze gtbase nepotrebuje glib2 jako zavislost?

[little.owl]

qtbase

[Michal Vyskočil]

No vlastně nepotřebuje. Ovšem drtivá většina distribucí taky integraci s glib main loop nevypíná.

[Rezza]

Jj, asi tak a hned rano jsem cetl nejaky mail od nejakeho fasisty, ktery na systemu nesmi mit nic g*. Od toho ale distribuce nejsou...

[Michal Vyskočil]

Jj, asi tak a hned rano jsem cetl nejaky mail od nejakeho fasisty, ktery na systemu nesmi mit nic g*.

Chtěl bych vidět, kterak nahradí glibc

[Rezza]

Lennart neco napise, neboj . Udelal to jakoby april a pritom uz ma urcite kod!

[pavlix]

A já si zas myslím, že tím odváděl pozornost od jeho nového network démona. Přecijen když si bude dělat furt srandu, tak to nebezpeční nebude nikdo brát vážně a než se naděješ… :D

[Michal Vyskočil]

Lennart neco napise, neboj .

Nejsem si jistý, že libc je jeho další projekt. Přeci jenom je to poměrně nudná knihovna, převážně definovaná spoustou dalších nudných norem, takže šance vymyslet naprosto novátorský přístup k řešení problémů moc není. Na druhou stranu se takto dá rozbít daleko více věcí, než zvládne PulseAudio a systemd dohromady

BTW: na druhou stranu, mít llibc by nebylo zase tak moc od věci.

[pavlix]

Přeci jenom je to poměrně nudná knihovna, převážně definovaná spoustou dalších nudných norem, takže šance vymyslet naprosto novátorský přístup k řešení problémů moc není.

O to větší je to challenge. On by ji napsal úplně mimo ty normy, nad tím by postavil compatibility layer a vývojáře by začal přesvědčovat, že POSIX je minulost. A pokaždé když se najde nějaká chyba, tak by vysvětlil, že to je kvůli tomu, že dotyčný používá tu POSIX vrstvu a ať přejde na nativní funkce.

[little.owl]

Ale, no tak, snad nejste vsichni Lennart's haters ...

Lennart ma muj respekt, to neni sranda konstruktivne nasirat takove mnozstvi lidi a pritom si zachovavat znacny vliv.

[pavlix]

Ale, no tak, snad nejste vsichni Lennart's haters ...

Trochu mi uniká, proč to píšeš pod mým příspěvkem. Tohle není žádný hate. To je jen parafráze na realitu toho, co skutečně jinde dělá. Vždyť stačí to chvíli sledovat. Dokonce jsem v rámci celého textu nepoužil jediné hodnotící slovo.

Mám podezření, že jsi se v tomhle případě chytil na přání otcem myšlenky, kdy jsi našel hate jen díky tomu, že jsi ho hledal.

Lennart ma muj respekt, to neni sranda konstruktivne nasirat takove mnozstvi lidi a pritom si zachovavat znacny vliv.

Ze stejného důvodu má i můj respekt. Mě osobně sere jenom jednou za čas, kdy se sere přímo do mojí práce. Pokud jde o problémy, které způsobuje všem, to je jejich problém, že si to nechají líbit.

[little.owl]

Trochu mi uniká, proč to píšeš pod mým příspěvkem.

Jsi v tom nevinne, to byla spise reakce na cely thread.

Mám podezření, že jsi se v tomhle případě chytil na přání otcem myšlenky, kdy jsi našel hate jen díky tomu, že jsi ho hledal.

Mozna ano; citil jsem z techto narazek trochu skodolibosti, asi jsem uz negativne poznamenan reakcemi lidi pro ktere je LP cerveny hadr.

[pavlix]

Mozna ano; citil jsem z techto narazek trochu skodolibosti, asi jsem uz negativne poznamenan reakcemi lidi pro ktere je LP cerveny hadr.

A to zas jo. Trocha škodolibosti v tom určitě byla, ale spíš v tom, že nebýt vázaný POSIXem kvůli kompatibilitě (a případně stávající sadou linuxových syscallů), tak by asi nikdo dneska nepostavil základní knihovnu tak, jak je postavená teď.

[stativ]

To jsem původně chtěl napsat taky, ale pak jsem si vzpomněl na Debian a EGlibc.

[Michal Vyskočil]

Nojo, přejmenování, to mě vážně nenapadlo. Takže Rezza může do Fedory navrhnout nahrazení g* za eg* (+ nějaké ty neupstreamové patche už nejspíše všude mají) a problém s g* hatery vyřešen

[pavlix]

A problém s embedded fanatiky taky.

[little.owl]

Tak to sotva.

[pavlix]

Vždyť to má to v názvu e! Proto přece vznikla eglibc, ne? :D

[little.owl]

To byl jen osklivy trik jak se zbavit Ulricha Dreppera .

[pavlix]

Ale ten už není a pořád se udržuje fork.

[little.owl]

Tak eglibc ma sve nesporne vyhody, ale porad to je jen ucesana modularnejsi glibc, nic co by utesilo embedded fanatiky. Ti maji problem s Linuxem jako takovym, s virtual memory, s heapem; prijatelna by snad mohla byt uclibc.

[pavlix]

Tak eglibc ma sve nesporne vyhody, ale porad to je jen ucesana modularnejsi glibc, nic co by utesilo embedded fanatiky.

Nevím, já měl za to, že fanatici obvykle předmětu svého fanatismu příliš nerozumějí. Měl jsem za to, že uclibc a busybox jsou primárně doménou pragmatiků, kteří potřebovali stlačit velikost komponent pod nějaký reálný limit.

[little.owl]

fanatici obvykle předmětu svého fanatismu příliš nerozumějí.

S tim jsem nemel problem, vetsinou rozumeli, s temi co nerozumi lze vymest.

doménou pragmatiků, kteří potřebovali stlačit velikost komponent pod nějaký reálný limit.

Ano, a to je asi hlavni duvod proc se s ni trapit, vedle jednoduzsi modifikace. Prave fanatici by to [nekdy iracionalne] cpali i tam kde je takovy pozadavek jen okrajovy, casto z principu.

[little.owl]

Vypada to tak. Nakonec jsem se kouknul na qtbase i qt5, skutecne tam udelali hezky kus prace.

[pavlix]

To je dobře.

[Petr Ježek]

Jakoby nestačil QTFM. Pro každou platformu je dobře použitelný FM.

[David Šmíd]

Díky za odkaz, není to ani tak o portování aplikací, jako spíše o přechodu z GTK+ na Qt pro toho, kdo dosud používal jen GTK+.

Ta wiki stránka mi připomněla, proč vlastně nesnáším GTK+. Používat neobjektový jazyk pro objektový toolkit je hrozná hovadina.

 

---

[pavlix]

Ta wiki stránka mi připomněla, proč vlastně nesnáším GTK+. Používat neobjektový jazyk pro objektový toolkit je hrozná hovadina.

Tvé problémy na mojí hlavu.

[Rezza]

Takhle - glib aspon dava knihovnam jednotny raz, ale to je fakt vse. Zvlast "metody" ve stylu this_is_my_namespace_and_this_is_my_fcking_class_with_this_my_uber_super_overloaded_method_with_one_int je zabava :D

Ale na druhou stranu nevidim duvod pro port, zvlast pokud chteji udrzovat obe verze.

[David Šmíd]

Přesně to jsem měl na mysli. Hned první bod na wiki hezky demonstruje tu "eleganci" GTK+:

Object construction

GObject Way:

Have to do initialize in four places.
class init function
Object constructor function, handle construction properties
Object init function
The *_new() function for the object

Qt Way:

Just use a normal C++ constructor and C++ "new" operator

---

[Rezza]

Jj. I kdyz mluvit v pripadku Qt jako o normal C++ je taky... (nastesti)

[pavlix]

To srovnání by takhle napsané dávalo smysl, kdyby GObject šel používat jen z C.

[David Šmíd]

Problém s gtkmm, jakož i se všemi dalšími wrappery je, že budou vždy pozadu za nativním API, řešení netriviálního problému s toolkitem bude často stejně vyžadovat pohled pod kapotu nativní knihovny a není zaručeno, že daný wrapper bude vyvíjen i v budoucnu.

Žádný wrapper navíc nikdy nemůže být 1:1 ekvivalentem nativní knihovny, vždy budou existovat problémy spočívající v rozdílech mezi oběma jazyky.

 

---

[pavlix]

Problém s gtkmm,

Ano.

jakož i se všemi dalšími wrappery je, že budou vždy pozadu za nativním API,

Ne.

Popravdě řečeno chápu tvé hodnocení situace na základě tvých současných znalostí, ale dneska se GObject používá trochu jinak než dřív. Ale to není na jeden komentář v diskuzi.

Žádný wrapper navíc nikdy nemůže být 1:1 ekvivalentem nativní knihovny, vždy budou existovat problémy spočívající v rozdílech mezi oběma jazyky.

To říkej třeba Pythonistům, kteří mají většinu svých stěžejních knihoven napsaných v cizím jazyce. V obecné rovině máš svým způsobem pravdu, při kombinování programovacích jazyků vznikají různé problémy, jen si nemyslím, že to je dosatečný důvod jazyky v menší míře nekombinovat.

[little.owl]

Žádný wrapper navíc nikdy nemůže být 1:1 ekvivalentem nativní knihovny, vždy budou existovat problémy spočívající v rozdílech mezi oběma jazyky.

To říkej třeba Pythonistům, kteří mají většinu svých stěžejních knihoven napsaných v cizím jazyce.

Ano, je komicke to rikat v pripade C, kdyz vetsina interpreteru, kompilatoru ci knihoven je napsana prave v C, tudiz s nim neni, a kdy asi nelepsi cesta jak napsat portovatelny kod ci knihovnu je prave C.

[little.owl]

... tudiz s nim neni problem

[David Šmíd]

Ano, C je takový nejmenší společný jmenovatel. Když chce někdo napsat široce využitelnou knihovnu, napsat ji v C dává smysl.

Ale programovat v tom GUI mě nikdo nepřinutí.

 

---

[little.owl]

Ale programovat v tom GUI mě nikdo nepřinutí.

Fanatismus?

[David Šmíd]

Říkej si tomu jak chceš.

 

---

[jurasn]

GUI v čistém C? Provozoval jsem naposled na PalmOS 3.5 ...

[kralyk z abclinuxu]

Ale programovat v tom GUI mě nikdo nepřinutí.

+1.

[little.owl]

Presne tak. Pokud nekdo chce udelat binding s jinymi jazyky, neni C a GObject vubec spatne reseni; ostatne proto to bylo takhle navrzeno. C++ je na portovatelne interface nocni mura.

[David Šmíd]

Možná by bylo bývalo lepší, kdyby tvůrci GTK+ navrhli C knihovnu jen jako interní základ, jehož použití by se doporučovalo jen otrlým C-only hackerům a tvůrcům bindingů do ostatních jazyků.

Na jeho základě by pak bývali mohli postavit skutečně objektovou knihovnu v C++ jako oficiálně doporučované API, přičemž by se oni sami postarali o hladké spojení s C knihovnou.

Bohužel nežijeme v ideálním světě.

 

---

[little.owl]

To by nefungovalo, ta C++ vast by nakonec nejak ujela a staly by se z toho v podstate nezavisle projekty.

[kralyk z abclinuxu]

To závisí na managementu toho projektu. Vůbec by to tak nemuselo být. A naopak podobné problémy platí pro knihovnu psanou v C/GObject. Ono totiž je sice hezké, že to je volatelné z jakéhokoli jazyka, ale za dost velkou cenu: Za cenu použití GObject konvencí, které jsou příšerné. Takže pokud budeš chtít, aby cílový jazyk mohl tvou knihovnu použít stejně pohodlně, jako svou nativní, budeš stejně muset napsat a udržovat wrappery pro ostatní jazyky (C++, Python,...).

Takže suma sumárum, pokud se chystáš psát knihovnu s bindingy do ostatních jazyků, není mezi C/GObject a C++ drastický rozdíl. Obojí se dá udělat a obojí vyžaduje podobné úsilí a údřžbu, má-li to být realizováno kvalitně.

[little.owl]

To závisí na managementu toho projektu. Vůbec by to tak nemuselo být.

Ja jsem zde skeptik. Lidi, kteri umi myslet dobre v C++ a zaroven v C neni moc a vetsinou je to nejaky hybrid.

Za cenu použití GObject konvencí, které jsou příšerné. Takže pokud budeš chtít, aby cílový jazyk mohl tvou knihovnu použít stejně pohodlně, jako svou nativní, budeš stejně muset napsat a udržovat wrappery pro ostatní jazyky (C++, Python,...).

Nic neni zadarmo. Konvence jsou nutne, viz zde a prave GObject Introspection, zejmena psani bindingu, naopak zjednodusuje. Navic lide pisici bindings do jinych jazyku, napsanych casto v C, nebudou z C++ a jeho problemu na interfacech rozhodne hykat nadsenim.

Takže suma sumárum, pokud se chystáš psát knihovnu s bindingy do ostatních jazyků, není mezi C/GObject a C++ drastický rozdíl.

To je snad vtip. Rozdil je masivni, srovnejte jen calling konvenci a veci jako name mangling, RTTI, implementace vyjimek, plne implementacne zavislou vnitrni reprezentaci C++ objektu atd. C [i s GObject] nevytvori takovou kupu moznych problemu jako C++. Pokud knihovnu v C++, tak jedine s cistym C interface, bez vyjimek a RTTI.

[kralyk z abclinuxu]

Nic neni zadarmo. Konvence jsou nutne, viz zde a prave GObject Introspection, zejmena psani bindingu, naopak zjednodusuje.

To bych se musel GObject introspection nějak probrat, abych to mohl posoudit. Jinak Qt dělá podobné psí kusy s objekty a metadaty o objektech. Nepovažuju tyhle věci za až tak úžasnou věc.

Mimochodem, píšou tam: "However, writing complex software is difficult and error-prone without garbage collection." LOL

To je snad vtip. Rozdil je masivni, srovnejte jen calling konvenci a veci jako name mangling,...

Nepochopil jsi mě. Jasně, že nebudeš psát binding přímo pro C++ interface, to je opravdu dost obtížný. Uděláš to tak, že napíšeš C interface pro C++ knihovnu, což díky možnosti C linkage v C++ není velký problém a dají se pořešit výjimky a další věci. A následně všechny ostatní bindingy můžeš napsat nad tímto C interface úplně stejně jako nad knihovnou v C nebo C/GObject.

[little.owl]

Jinak Qt dělá podobné psí kusy s objekty a metadaty o objektech.

Rozdil je v tom, ze GObject vesmes pouziva veci specifikovane v C standardu, kdezto C++ veci vesmes implementacne zavisle, a u Qt navic casto zavisejici na moc.

Nepochopil jsi mě.

Podle popisu to presne odpovida tomu co jsem nakonec psal. Ale stejne to neresi nektere problemy u low level knihoven. Mnohokrat jsem byl v situaci, kdy mi pouzita knihovna padala v release verzi a ja mel jen memory dump, build map a asm listing, a doslova analyzoval raw data. V pripade C to jeste celkem jde, v pripade C++, zejmena na proprietarnim kompilatoru, je to mnohem, mnohem horsi, ten bordel co to nkedy udela na stacku je neuveritelny. Ja nezpochybnuji C++, ale pro systemovy a portovatelny kod je lepsi C.

[kralyk z abclinuxu]

V pripade C to jeste celkem jde, v pripade C++, zejmena na proprietarnim kompilatoru, je to mnohem, mnohem horsi, ten bordel co to nkedy udela na stacku je neuveritelny. Ja nezpochybnuji C++, ale pro systemovy a portovatelny kod je lepsi C.

To mi oboje přijde jako unáhlené zobecnění. Imho závisí na konkrétních případech. Bordel se dá udělat v C stejně dobře jako v C++. Jinak to, že v C++ je name mangling a ABI výjimek necháno na kompilatoru, považuju za dost velkou nevýhodu a není mi úplně jasný, proč v tomhle nechala C++ komise implementacím volnou ruku. Jednotné ABI by mělo nesporné výhody.

Jinak "systémové věci" (myšleno kernel, drivery apod.) bych taky psal v C, ale považuju to za osobní preferenci, ne za dogma

[little.owl]

To je moje zkusenost po nekolika letech s nekolika C++ kompilatory na embedded aplikacich a to byly doby kdy jsem byl schopen nadsene psat v C++ i interrupt handlery; chybama se clovek uci.

ABI výjimek necháno na kompilatoru

To je extremne HW zavisle, pokud maji byt vyjimky implementovany efektivne.

[kralyk z abclinuxu]

Hm, no tak alespoň ten name mangling mohl být jednotný...

[little.owl]

Podle me take, ale tvurcove standardu se spolu s tvurci kompilatoru shodli, ze je to spise implementacne zavisle. Navic je to celkem fuk, bez standardizace implementace C++ objektu je to temer k nicemu a to je take HW zavisle, pokud to ma byt efektivni, stejne jako dynamicky binding a RTTI, a C++11 to se svou atomicitou udelalo jeste horsi.

Neni uniku, C++ je ve sve podstate oproti C high level jazyk se vsemi dusledky.

[vencas]

Jasně, že nebudeš psát binding přímo pro C++ interface, to je opravdu dost obtížný.

To přesně dělám, boost::python se postará o propojení počítání reference v python a c++ (shared_ptr), o zachytávání c++ vyjímek a převedení na pythoní vyjímku, převádění typů, takže funkce může brát či vracet c++ typy, přetěžování funkcí atd atd. Nedokážu si představit, že bych šel přes c a pak teprve do pythonu.

Vedle toho binding nepíšu ručně, ale starají se o to šikovná makra, která do pythonu vyexportují všechny data members ve třídě, četně dokumentace.

[kralyk z abclinuxu]

No jo, to je ale specifikum boost::python. Máš tuhle možnost i u ostatních jazyků? Imho takhle promakaná vrstva je spíš výjimkou...

[vencas]

To je asi pravda, naštěstí ale žádný jiný jazyk nepotřebuju.

[little.owl]

Ma to sve limity, stejne jako SWIG ci Cython, staci se kouknout do FAQ ci TODO listu, navic vyvoj vypada podle logu a dokumentace v poslednich letech polomrtve. Pokud CPython chcete skutecne pouzit v C/C++, je nejlepsi pouzit primo poskytovane C API.

Nedokážu si představit, že bych šel přes c a pak teprve do pythonu.

Spatna predstavivost.

[vencas]

Pokud CPython chcete skutecne pouzit v C/C++, je nejlepsi pouzit primo poskytovane C API.

Já ho ale už "skutečně používám", dokonce několik roků :) C API jenom v nejhorším, když není zbytí, s tím že kombinace boost::python a C API je bezproblémová.

[pavlix]

Možná by bylo bývalo lepší, kdyby tvůrci GTK+ navrhli C knihovnu jen jako interní základ, jehož použití by se doporučovalo jen otrlým C-only hackerům a tvůrcům bindingů do ostatních jazyků.

A vznikla by situace naprosto ekvivalentní té aktuální. Lidi neposlouchají doporučení. Minimálně tvůrci věcí okolo GObject introspection jsou zcela jistě toho stejného názoru.

Na jeho základě by pak bývali mohli postavit skutečně objektovou knihovnu v C++ jako oficiálně doporučované API

Proč by se zabývali C++, které potřebuje bindingy na jednotlivé knihovny, když mají jazyky, kterým stačí jeden binding pro všechny knihovny? Musel bys buď jednotlivě přesvědčit autory knihoven, aby C++ bindingy generovali nebo bys je musel generovat v rámci aplikace, která je chce používat.

C++ má oproti dynamickým jazykům zásadní výhodu v rychlém kódu. Ale v případě GUI frontendů není ta výhoda zdaleka tak markantní a tudíž je motivace komplikovat si život s C++ mnohem menší.

Na jeho základě by pak bývali mohli postavit skutečně objektovou knihovnu v C++

Neměl jsi na mysli to, že by na jeho základě mohli používat syntaktický cukr v C++?

jako oficiálně doporučované API

Proč by měli oficiálně doporučovat jazyk, který jim nevyhovuje a u kterého nemají pocit, že by jim něco přinášel?

Bohužel nežijeme v ideálním světě.

To rozhodně ne :).

[pavlix]

A ještě jedna drobnost, to že C++ je velmi omezené se dá považovat za výhodu i za nevýhodu. Objektový model v GLib je v podstatě na roveň s objektovým modelem Pythonu, což je v C takový malý zázrak.

[David Šmíd]

Ať už je objektový model v GLib jakýkoli (nevím o ničem z Pythonu, co by v C++ vyloženě chybělo), bez syntaktického cukru to bude vypadat příšerně (čitelnost kódu blízká nule) a programovat se v tom bude ještě hůře.

Je to jako používat Postscript na matematické výpočty: sice to jde, ale proč to proboha dělat, když existuje mnoho vhodnějších jazyků.

 

---

[little.owl]

bez syntaktického cukru to bude vypadat příšerně (čitelnost kódu blízká nule) a programovat se v tom bude ještě hůře

Prasit lze v jakemkoliv jazyku.

Zacina se to posouvat do roviny C vs. C++, objektove versus proceduralni programovani, ale to jsme uplne jinde.

[pavlix]

Zacina se to posouvat do roviny C vs. C++, objektove versus proceduralni programovani, ale to jsme uplne jinde.

Spíše objektové programování s cukrem versus objektové programování bez cukru. Já jsem každopádně rád, že je třeba takový Python napsaný v C a ne v C++.

[David Šmíd]

Ano, proti procedurálnímu programování ani proti C jako takovému nic nemám.

Jen si myslím, že jazykem první volby pro práci s objektovým toolkitem by měl být objektový jazyk, ať už je to C++, Objective C, Smalltalk, Vala, Go nebo Python.

 

---

[pavlix]

Jak už jsem jednou poznamenal, to říkej tvůrcům Pythonu, kteří jako základní jazyk pro práci s objektovým modelem Pythonu zvolili C.

[kralyk z abclinuxu]

A jak moc bys poznal, kdyby zvolili C++? Zrovna u implementace pythonu mi přijde, že to má mnohem menší dopad než u GUI toolkitu.

[pavlix]

A jak moc bys poznal, kdyby zvolili C++?

Podle toho, co bych dělal, že. Pokud bych debugoval nějaké moduly a řešil bych jak balast, který přidává C++, tak balast, který přidávají pythoní struktury, tak bych se třeba trochu kousal do rtu.

Zrovna u implementace pythonu mi přijde, že to má mnohem menší dopad než u GUI toolkitu.

Pokud bys ten toolkit používal z pythonu, lua, javascriptu a podobných, tak by ti to v podstatě mohlo být taky jedno.

Ten rozdíl není až tak zásadní, ale je zajímavé vidět, že tu mezivrstvu, co poskytuje C++ (pokud se na to dívám z pohledu postupného odlepování se od skutečného fungování procesoru) se mnozí z nějakého důvodu nerozhodli použít. A nějak mi nepřijde, že by tím trpěli nebo že by to způsobovalo třeba tomu Pythonu nějaké zásadní problémy.

[kralyk z abclinuxu]

Ten rozdíl není až tak zásadní, ale je zajímavé vidět, že tu mezivrstvu, co poskytuje C++ (pokud se na to dívám z pohledu postupného odlepování se od skutečného fungování procesoru) se mnozí z nějakého důvodu nerozhodli použít. A nějak mi nepřijde, že by tím trpěli nebo že by to způsobovalo třeba tomu Pythonu nějaké zásadní problémy.

No tak C++ určitě není Jediná Správná Cesta, to v žádným případě. Jinak já všeobecně nejsem proti implementaci OOP v C, pokud se to realizuje nějak rozumně, výhrady mam spíš specificky proti GObject/GTK. V tomhle ohledu je mi ten CPython sympatický v tom, že se v něm nepokusili nahradit C++ GObjectem, ale šli vlastní cestou...

[pavlix]

výhrady mam spíš specificky proti GObject/GTK

To je ale v rámci diskuze novinka. Zatím jsi výhrady konkrétně proti GObject/GTK neměl a už vůbec ne konkrétní výhrady. Je legrační, jak se někdy člověk vehementně hrne do hádky aniž by si nejprvě ověřil, že je o čem se hádat a že vybraný člověk má na věc dostatečně odlišný názor, aby to za flamewar vůbec stálo ;).

V tomhle ohledu je mi ten CPython sympatický v tom, že se v něm nepokusili nahradit C++ GObjectem, ale šli vlastní cestou...

Je zajímavé, jak dokážeš u dvou konceptuálně téměř stejných modelů určit, že jeden z nich je takový za špatným účelem a druhý za dobrým.

[kralyk z abclinuxu]

To je ale v rámci diskuze novinka. Zatím jsi výhrady konkrétně proti GObject/GTK neměl a už vůbec ne konkrétní výhrady. Je legrační, jak se někdy člověk vehementně hrne do hádky aniž by si nejprvě ověřil, že je o čem se hádat a že vybraný člověk má na věc dostatečně odlišný názor, aby to za flamewar vůbec stálo ;).

Tak ta diskuse doufám nebyla o C vs C++. Každopádně viz můj první komentář v diskusi, to bylo, proč jsem začal flamovat. Ale asi se to mezitim trochu posunulo.

Je zajímavé, jak dokážeš u dvou konceptuálně téměř stejných modelů určit, že jeden z nich je takový za špatným účelem a druhý za dobrým.

To je jednoduché: CPython není GUI toolkit. A za témeř stejné modely bych to neoznačil, ačkoli neznám střeva CPythonu, pouze jsem se probíral jejich C API.

[little.owl]

To je jednoduché: CPython není GUI toolkit. A za témeř stejné modely bych to neoznačil, ačkoli neznám střeva CPythonu, pouze jsem se probíral jejich C API.

GLib take neni toolkit a objektovy model GTK je dan tim, ze je to postaveno na/pracuje s GLib/GObject a napsano v C.

[kralyk z abclinuxu]

Historicky to je ale obráceně - GLib vzniklo vydělením z GTK. Imho měli tenhle krok dotáhnout do konce a GObject použít v GTK pouze pro low-level záležitosti a nad ním postavit pro vývojáře GUI aplikací nějaký vhodnější interface. Což je přesně to, co se nakonec stalo, bohužel ale až o hodně později, tzn. jednak Vala, vytvořená specificky coby nadstavba nad GObject, a dále orientace Gnome 3 na další vyšší jazyky.

[pavlix]

Teď už snad sám vidíš, že pokus o flame byl zbytečný, když až na opravdové marginality tvrdíš to, co samé, co já :D.

[little.owl]

Je zajímavé, jak dokážeš u dvou konceptuálně téměř stejných modelů určit, že jeden z nich je takový za špatným účelem a druhý za dobrým.

To me take velmi pobavilo.

Nekteri nejsou schopni pochopit, ze GObject je snaha o naprosto minimalisticky objektove orientovany model/API implementovany v neobjektovem jazyce C, ktery byl designovan jako pouzitelny ve vsech objektovych i neobjektovych jazycich a knihovnach napsanych v/pouzitelnych s C. Tohle uz s velmi specifickym high level objektovym modelem v C++ udelat v podstate nelze.

[kralyk z abclinuxu]

Nekteri nejsou schopni pochopit, ze GObject je snaha o naprosto minimalisticky objektove orientovany model/API implementovany v neobjektovem jazyce C, ktery byl designovan jako pouzitelny ve vsech objektovych i neobjektovych jazycich a knihovnach napsanych v/pouzitelnych s C.

Ale ne, tohle imho všichni zúčastnění chápou. Co někteří, zdá se mi, moc nechápou, je, že GObject se dost dobře nedá postavit na roveň objektovým modelům z vyších jazyků. Oproti nim to není "portovatelnější evivalent", ale spíš kompromis, který přináší nějaké výhody, ale i nějaké nevýhody.

Tohle uz s velmi specifickym high level objektovym modelem v C++ udelat v podstate nelze.

O objektovým modelu v C++ bych určitě neřekl, že je "velmi specifický", v C++ se dají implementovat všelijaký objektový modely. (A jsem přesvědčen, že ekvivalent GObject by v C++ klidně udělat šel, nevidím v tom problém.) Jiné jazyky mají mnohem specifičtější objektový modely (Java,...).

[little.owl]

Co někteří, zdá se mi, moc nechápou, je, že GObject se dost dobře nedá postavit na roveň objektovým modelům z vyších jazyků.

Budiz.

Oproti nim to není "portovatelnější evivalent", ale spíš kompromis, který přináší nějaké výhody, ale i nějaké nevýhody.

Nikdo snad netvrdi, ze je to ekvivalent. V okamziku, kdy cilite na pouzitelnost v mnoha jazycich, kompromis je nutny.

O objektovým modelu v C++ bych určitě neřekl, že je "velmi specifický", v C++ se dají implementovat všelijaký objektový modely.

Chovani objektu v C++ je celkem jasne dano standardem a je specificke. Jine modely lze implementovat, ale bude tam stejny problem jako s pokusem je implementovat objekty v C - tedy bez rozumne podpory jazyka.

[kralyk z abclinuxu]

Chovani objektu v C++ je celkem jasne dano standardem a je specificke. Jine modely lze implementovat, ale bude tam stejny problem jako s pokusem je implementovat objekty v C - tedy bez rozumne podpory jazyka.

Jasný no, souhlasim, že se to nedá nějak radikálně změnit, aniž by člověk musel dělat něco jako GObject (nebo Qt, že...), měl jsem na mysli takový menší nuance jako např. smart poitnery vs normální pointery, RAII vs non-RAII apod...

[Rezza]

Ja proti GObject vecem obecne nic nemam, ale ta (ne)citelnost kodu je fakt silena.

[little.owl]

Ano, GObject je komplikovany, to beru, nic neni zadarmo.

[pavlix]

Ať už je objektový model v GLib jakýkoli (nevím o ničem z Pythonu, co by v C++ vyloženě chybělo),

Když je člověk zvyklý žít v jeskyni, taky mu to, co je venku, nechybí. Jistě najdeš člověka, třeba mezi kernelovými vývojáři, který ti řekne, že neví o ničem z C++, co by mu v C vyloženě chybělo.

bez syntaktického cukru to bude vypadat příšerně (čitelnost kódu blízká nule)

Věc zvyku. Francouzština je taky divný jazyk a taky se s ní hromada lidí po světě v pohodě domluví.

a programovat se v tom bude ještě hůře.

Asi nemá smysl abych to hodnotil. Programování naštěstí není jen o syntaktickém cukru.

Je to jako používat Postscript na matematické výpočty: sice to jde, ale proč to proboha dělat, když existuje mnoho vhodnějších jazyků.

To zní z úst člověka, který používá C++ dost divně. Netvrdím, že se v tom nedá programovat, ale co do čistoty návrhu je to strašný paskvil.

[little.owl]

To zní z úst člověka, který používá C++ dost divně. Netvrdím, že se v tom nedá programovat, ale co do čistoty návrhu je to strašný paskvil.

Tak bych to nerekl, ale gotchas je tam plno a ucici krivka C++ je velmi dlouha. Kazdopadne opravit/refaktorovat spatne napsane C++ aplikace bylo pro nas vzdy tezsi nez spatne napsane C aplikace; to o necem take vypovida.

[David Šmíd]

Když je člověk zvyklý žít v jeskyni, taky mu to, co je venku, nechybí.

Znám možnosti Pythonu, jen mezi nimi nevidím nic, co by mi v C++ 11 vyloženě chybělo. Možná je to věc názoru.

Věc zvyku. Francouzština je taky divný jazyk a taky se s ní hromada lidí po světě v pohodě domluví.

Francouzština je jazyk jako každý jiný.

Naproti tomu C prostě objektový jazyk není, i kdyby ses na hlavu stavěl, objektovost se v něm jen předstírá a všelijak hackuje.

Programování naštěstí není jen o syntaktickém cukru.

Ne, není, ale takové věci jako syntaktický cukr ohromně zvyšují přehlednost a produktivitu. Při programování pak nemám pocit permanentní nasranosti z toho, jak musím pořád dokola opisovat zřejmé věci.

Netvrdím, že se v tom nedá programovat, ale co do čistoty návrhu je to strašný paskvil.

Ano, čistota návrhu v C++ leckde ustoupila praktickým ohledům a já jsem tomu rád. K čemu by byl superčistý jazyk, který nikdo nepoužívá, protože je zoufale nepraktický (Smalltalk).

 

---

[little.owl]

Naproti tomu C prostě objektový jazyk není, i kdyby ses na hlavu stavěl, objektovost se v něm jen předstírá a všelijak hackuje.

Michate veci dohromady. Nikdo netvrdil, ze C je objektove orientovany jazyk. Jen GObject framework je knihovna napsana v C, ktera poskytuje "object-oriented C-based API". Nic vice, nic mene.

Ano, čistota návrhu v C++ leckde ustoupila praktickým ohledům a já jsem tomu rád. K čemu by byl superčistý jazyk, který nikdo nepoužívá, protože je zoufale nepraktický (Smalltalk).

Vetsina problemu vznikla postupnou evoluci a snahou nerozbit zpetnou kompatibilitu nebo ruznymi edomyslenostmi; kazdy pouzivany neakademicky jazyk ma tento problem.

[David Šmíd]

Michate veci dohromady. Nikdo netvrdil, ze C je objektove orientovany jazyk. Jen GObject framework je knihovna napsana v C, ktera poskytuje "object-oriented C-based API". Nic vice, nic mene.

Jediné, co se snažím tvrdit je, že výrazové prostředky čistého C jsou v oblasti objektově orientovaného přístupu značně chabé.
Používat C je objektovému programování je prostě nepřirozené.

 

---

[pavlix]

Jediné, co se snažím tvrdit je, že výrazové prostředky čistého C jsou v oblasti objektově orientovaného přístupu značně chabé.

To je ale subjektivní hodnocení. Já bych spíše neutrálněji řekl, že jsou primitivní. Pomocí primitivních prostředků toho jde často vyjádřit mnohem víc než pomocí sofistikovaných, i když pracněji. To je podle mě typický rozdíl mezi nízkoúrovňovými a vysokoúrovňovými nástroji.

C++ je ještě zajímavé v tom, že obsahuje většinu C, takže vlastně pracuje na dvou různých úrovních, té nízké céčkové a k ní přidává konkrétní objektový model a k němu syntaktický cukr. Jestli je je to dobře nebo špatně, to už si může každý posoudit sám.

Používat C je objektovému programování je prostě nepřirozené.

Vidíš a tvůrcům Pythonu to zrovna přišlo jako přirozená volba. A vlastně i tvůrcům mnoha dalších jazyků a frameworků včetně C++.

[smazáno]

Ne, není, ale takové věci jako syntaktický cukr ohromně zvyšují přehlednost a produktivitu. Při programování pak nemám pocit permanentní nasranosti z toho, jak musím pořád dokola opisovat zřejmé věci.

A rikas ze ti v C++ 11 nic z pythonu nechybi? Mimochodem, jake pouzivas IDE na C++?

[David Šmíd]

Trochu nepřekvapivě QtCreator

 

---

[pavlix]

Naproti tomu C prostě objektový jazyk není, i kdyby ses na hlavu stavěl,

Možná jsme si špatně rozuměli. Já zde nevedu náboženskou válku.

Programovací jazyk C vnímám jako relativně tenkou do velké míry přenositelnou vrstvu nad assemblerem, který odráží schopnosti procesoru.

Céčko poskytuje všechny prostředky nutné pro naprogramování a používání objektového modelu, a to v nejpohodlnější možné formě, která neurčuje, jak ten model bude vypadat, alespoň podle mého názoru. Mezi tyto prostředky patří struktury, ukazatele včetně těch na funkce a pravidla pro zarovnání (např. garance, že první prvek struktury má stejnou adresu jako struktura).

objektovost se v něm jen předstírá a všelijak hackuje.

To je ale velký omyl. Objektovost, pokud tedy myslíš nějaký model/framework na bázi OOP, se v céčku nepředstírá, nýbrž vytváří. Stačí na chvíli zapomenout na náboženské přesvědčení a podívat se třeba zrovna na ten Python.

Rovnou můžeš tvrdit, že objektovost se v počítači pouze předstírá a hackuje. Takové tvrzení bude dávat úplně stejný (ne)smysl.

Nehledě na to, že lidé, kteří používají OOP se dělí mezi ty, kteří to berou jako náboženství a ty, kteří to berou jako nástroj. Já se snažím patřit spíše do té druhé a naštěstí mám kolem sebe pár lidí, kteří mi v tom pomáhají, když nemám dost času se v tom pohrabat sám. Ale samozřejmě chápu, že někoho programování může zajímat jen z té uživatelské stránky.

[kralyk z abclinuxu]

Rovnou můžeš tvrdit, že objektovost se v počítači pouze předstírá a hackuje. Takové tvrzení bude dávat úplně stejný (ne)smysl.

Ale vždyť je to pravda. OOP se v počítači předstírá a hackuje úplně stejně, jako se předstírají např. vícerozměrná pole a mnoho dalších věcí. A to samé platí pro OOP v C.

Ale to není jen omezení C, podobné platí i pro jazyky mnohem vyšší úrovně, např. namespaces v EcmaScriptu mě zrovna napadaj. Nebo v tom C++ se různě dohackovává introspekce/reflexe (podobně jako GObject).

Tady nemá cenu dělat z nouze ctnost. C prostě OOP nemá, nepodporuje, neobsahuje, stejně jako EcmaScript nepodporuje namespaces a C++ reflexi. To, že se dané featury dá nějakým způsobem docílit, na té charakteristice nic nemění.

[pavlix]

Ale vždyť je to pravda. OOP se v počítači předstírá a hackuje úplně stejně, jako se předstírají např. vícerozměrná pole a mnoho dalších věcí. A to samé platí pro OOP v C.

Rozhodně souhlasím s tím, že je to úplně stejné. Použití slov „předstírá“ a „hackuje“ mi přijde jako hodnocení či povzdech, že je na tom něco špatně. Nevidím, že by použití těch slov mělo nějaký objektivní význam nebo dopad.

Tady nemá cenu dělat z nouze ctnost.

Mě spíš přijde, že se někteří ani po těch desetiletí nedokážou smířit s tím, co je C za jazyk a jak je navržený. Rozhodně bych to neoznačoval za nouzi nebo chybu.

C prostě OOP nemá,

Přesně tak, jazyk žádné prvky OOP neimplementuje, neurčuje a neposkytuje pro ně tím pádem ani syntaktický cukr.

To, že se dané featury dá nějakým způsobem docílit, na té charakteristice nic nemění.

Nejsem si vědom toho, že bychom v tomto byli ve sporu.

[little.owl]

Co mate proti snaze o konzistentni naming konvenci?

[smazáno]

Jojojo, programovat gobject v C je peklo.

[little.owl]

Používat neobjektový jazyk pro objektový toolkit je hrozná hovadina.

Nevidim v tom zas tak velky problem, to je spise jen nabozenstvi.

Problem Qt fanatiku je navic i ten, ze cpou ten svuj bloated framework nejen do GUI a par veci okolo, ale i tam kde by stacilo pouzit C++ a standardni knihovny.

[Rezza]

I na blbeho sitoveho demonka si radsi pouziju QtNetwork :) Spis nez fanatik, jsem rozmlsany :D

[little.owl]

Pokud vam nevadi, ze az neco nebude optimalne fungovat, budete v mnohem horsi pozici a pokud vam nevadi vlacet pres zavislosti dalsi tuny kodu a knihoven, pak mozna ano.

[David Šmíd]

Ale no tak, nic mi nebrání použít na kritické části čisté C, mohu dokonce předefinovat jakoukoli metodu, s jejímž výkonem nejsem spokojen. V praxi ale spíše platí, že vlastní kód bude méně efektivní než to, co naprogramovali tvůrci Qt knihovny.

Závislosti budou jen dvě: QtBase a QtNetwork, nic strašného.

 

---

[little.owl]

Ale no tak, nic mi nebrání použít na kritické části čisté C, mohu dokonce předefinovat jakoukoli metodu, s jejímž výkonem nejsem spokojen.

C++ overriding neni zadana panacea, zalezi na konkretni implementaci objektu, predpoklada to znalost jeho vnitrni implementace a nakonec jste ji stejne limitovan.

QtBase a QtNetwork, nic strašného.

U embedded systemu to problem je, zejmena pokud musite davat 8 let zaruku a podporu, a nemuzete plytvat pameti.

[Rezza]

Tak Qt 5 bylo rozsekane prave pro embedded pouziti - melo to jit do tech nejlevnejsich smartphonu. A samozrejme, pokud je jeste slabsi hw, tak to nema smysl. Vse je o potrebach a proste kdyz neco delam, tak radsi zvolim neco, co me to umozni a splni aspon castecne me pozadavky, nez fanaticky trvat na Q*, G*, C*, B*

[little.owl]

Vse je o potrebach a proste kdyz neco delam, tak radsi zvolim neco, co me to umozni a splni aspon castecne me pozadavky, nez fanaticky trvat na Q*, G*, C*, B*

+1

[pavlix]

+1