Přenositelné GUI? GTKMM!

14.1.2006 21:54 | Přečteno: 2608× | Dev/Tech/Gnu | poslední úprava: 15.1.2006 01:08

Do diplomky potřebuji trošku grafického uživatelského rozhraní. Budu tam mít taky nějaký legacy (češtináři prominou) kód v plain C. Své rozšíření budu psát v C++. Chci si to vyvíjet v Linuxu, ale musí to běžet i na Windows, protože s tím budou pracovat studenti a nemůžu nikoho diskriminovat.

Původně jsem to chtěl udělát v GTK, teď jsem ale objevil gtkmm, což není nic jiného, než tenký C++ wrapper nad plaincéčkovým GTK. Musím říct, že se mi to dost líbí, protože:

• C++ kód umí být přehlednější než čísté céčko. GTK je "objektové", což je sice fajn, ale díky jazyku občas kostrbaté.
• Lepší typová kontrola, hlavně u handlerů.
• Lepší licence - LGPL na rozdíl od Qt s GPL.
• Na rozdíl od Qt je to čisté C++, žádný preprocesor a podobné nechutnosti.

Windoze

Takže jsem vzal nejjednodušší appku, co jde napsat a zkusil to přeložit pod Windows.

// Simple gtkmm app - simple.cpp
#include <gtkmm.h>

int main(int argc, char *argv[])
{
    Gtk::Main kit(argc, argv);
    Gtk::Window window;
    Gtk::Main::run(window);
    return 0;
}

Pak se to trochu podobalo hackování xchatu. Jen jsem musel kromě GTK nahodit ještě port gtkmm a všechny závislosti (gdk, pango, cairo, atk, ...), což je po rozbalení přes 7000 souborů a z disku to ukousne čtvrt giga. Výše uvedený zdroják se přeloží jednoduše

c:\dev-cpp\bin\g++ -o simple.exe simple.cpp -Ic:/gtk/include/gtk-2.0 -Ic:/gtk/lib/gtk-2.0/include -Ic:/gtk/include/atk-1.0 -Ic:/gtk/include/pango-1.0 -Ic:/gtk/include/glib-2.0 -Ic:/gtk/lib/glib-2.0/include -Lc:/gtk/lib -lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangowin32-1.0 -lgdi32 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -liconv -mms-bitfields -mwindows -Ic:/gtk/include/gtkmm-2.4 -Ic:/gtk/include/gdkmm-2.4 -Ic:/gtk/include/glibmm-2.4 -Ic:/gtk/include/pangomm-1.4 -Ic:/gtk/include/atkmm-1.6 -Ic:/gtk/include/sigc++-2.0 -latkmm-1.6 -lgtkmm-2.4 -lglibmm-2.4 -latkmm-1.6 -lgdkmm-2.4 -lpangomm-1.4 -lsigc-2.0 -Ic:/gtk/lib/glibmm-2.4/include -Ic:/gtk/lib/sigc++-2.0/include -Ic:/gtk/lib/gdkmm-2.4/include -Ic:/gtk/lib/gtkmm-2.4/include -I/gtk/include/cairo

Z těch závislostí opravdu moc happy nejsem. V c:/GTK/bin je 70 mega DLL-ek, asi nebudu potřebovat všechno, ale jen libgtkmm-2.4-1.dll má 13 mega. Už se těším, až to budu instalovat svému vedoucímu

Update:

Zkoušel jsem to linkovat staticky a nepovedlo se, ani v Linuxu. Ale zjistil jsem, že pro simple.exe stačí "jenom" tyto knihovny.

iconv.dll intl.dll libatk-1.0-0.dll libatkmm-1.6-1.dll libcairo-2.dll libfontconfig-1.dll libfreetype-6.dll libgdk-win32-2.0-0.dll libgdkmm-2.4-1.dll libgdk_pixbuf-2.0-0.dll libglib-2.0-0.dll libglibmm-2.4-1.dll libgmodule-2.0-0.dll libgobject-2.0-0.dll libgtk-win32-2.0-0.dll libgtkmm-2.4-1.dll libpango-1.0-0.dll libpangocairo-1.0-0.dll libpangomm-1.4-1.dll libpangowin32-1.0-0.dll libpng13.dll libsigc-2.0-0.dll xmlparse.dll xmltok.dll zlib1.dll

Což je "jen" 30 mega, prohnáno RARem necelých 6. Takže to přežiju.

       

Komentáře

[David Watzke]

LOL, hrozně se mi líbí to -IC:\.... Fakt krutý. Proč vůbec něco jde a něco ne na Windows? Céčko je snad všude stejný, huh? GTKmm též. :/

[David Watzke]

-IC:\..., -IC:/.... Opačně, jo?

[#Tom]

No jasně, jak jinak! Nejvíc mě potěšilo, že je hodně okenních programů, které toto spolknou bez remcání. Třeba správce souborů FAR, Microsoft Word a WinAMP.

[paskma]

Ono to totiž spolkne API. Přesněji fce CreateFile, která se používa (kupodivu) i k otvírání souborů. Teda myslím.

[#Tom]

Čekal bych to spíš od funkcí open, creat, fopen, mkdir a dalších, aby se snáze přenášely unixové programy. Ale WinAPI jsem nikdy do hloubky nezkoumal.

[paskma]

No tak CreateFile je taky jenom knihovní funkce, prostě API. Interně je tam něco jako NTCreateFile (tuším), teprve tam je skutečný systémový call na jádro.

Jinak v NT je nějaká posixová vrstva, ale jen tak ze srandy. Takovéto céčkové rozhraní je tuším v msvcrt.dll.

Hm. Tento příspěvěk je jistě plný nepřesností

[#Tom]

Mně se WinAPI nikdy nezalíbilo a nikdy jsem se jej nesnažil pořádně pochopit, takže o něm nevím skoro nic. :-/ (Běžné ANSI C + POSIX + BSD + další unixovosti a linuxovosti se mi líbí mnohem více.)

[Luboš Doležel (Doli)]

Já teda / používám ve Windows odjakživa. Nikdy jsem \ nepřišel na chuť.

[Luboš Doležel (Doli)]

Pokud je zdroják vašeho SW pod GPL/LGPL, můžete linkovat staticky... To se potom dostanete hluboko pod 0,5 MB.

[Luboš Doležel (Doli)]

...za předpokladu použití kvalitního kompilátoru = žádné mingw.

[paskma]

Hmm, tak to nevím.

Teď jsem koukal na windozí port xchatu a ten je linkovany proti minigtk.dll. Neznám, uvidím.

[paskma]

Knihovny jsou LGPL, takže to udělat můžu i kdyby moje licence byla od Ďábla. Ale v Linuxu mi to hodilo chybu, musím to ve Woknech zkusit.

paskma@paskma:~/tmp/gladepok/two$ g++ simple.cpp -o simple `pkg-config gtkmm-2.4 --cflags --libs` --static /usr/bin/ld: cannot find -lgtkmm-2.4 collect2: ld returned 1 exit status

[Luboš Doležel (Doli)]

Četl jste někdy licenci LGPL? LGPL != BSD. Uzavřený software se s LGPL knihovnami může linkovat pouze dynamicky.

[Luboš Doležel (Doli)]

Nebo staticky, pokud zveřejníte objektové soubory a umožníte tak relinkovat váš software s jinou verzí knihovny.

[..]

Opravdu to takhle jde delat? To sem v pravde netusil. Dik za informaci

[Luboš Doležel (Doli)]

Ano a další z podmínek je umožnit reverzní inženýrství vašeho software.

Už nevím, jak přesně je to míněno, ale asi tak, že to nebudete ve své licenci zakazovat.

[kar]

To je irelevantní, protože s Gtk+ staticky linkovat nejde. Resp. by se muselo velmi, velmi přiohnout.

Gtk+ natahuje pixbuf-loadery (načítání obrázků různých formátů), vstupní metody, renderovací moduly Panga pro různá písma, theme engines, a jánevímco za běhu (tj. dlopen() nebo jeho analogií na daném systém). Při statickém linkování se ti nemohou resolvnout symboly v modulech, takže žádný nenatáhneš. V nejlepším případě bude výsledkem jedoucí, ale zkriplené Gtk+.

Gtkmm to určitě nespraví, takže pro něj to platí též.

Nevím, co je všechno v tvé windowsí instalaci Gtkmm, ale Gtk+ (bez devel) má cca těch 13 MB celé.

[Luboš Doležel (Doli)]

Já taky neříkám, že staticky linkuju pixbuf loadery apod.

Nevím, co je všechno v tvé windowsí instalaci Gtkmm, ale Gtk+ (bez devel) má cca těch 13 MB celé.

Já mluvím o hotovém, slinkovaném EXE (pomocí VS.NET 2005).

[kar]

Pokud ale chceš, aby pixbuf loadery fungovaly, tak s sebou musíš tahat i ty dynamické knihovny, protože ony je potřebují. A pokoušet se linkovat staticky aplikaci v tom případě nejen nic nezlepší, ale vede k novým ,zajímavým` problémům (datové struktury v knihovnách...).

[Luboš Doležel (Doli)]

To je jasný, ale pokud staticky slinkuju, co se dá, zmenší se objem dat. Není mi jasné, proč by měly být problémy s datovými strukturami v knihovnách.

[Rezza]

Na tema "Na rozdíl od Qt je to čisté C++, žádný preprocesor a podobné nechutnosti." jsem videl ted krasny blog... Ve stylu proc to lidem v Qt vadi a v jinem software ne? No musim si zkusit foreach z Qt4, uz se tesim::D

[paskma]

Mě to vadí, protože mám rád standardy. Nejde o preprocesing samotný, proti std. preprocesoru z céčka nic nemám.

[Miloslav Ponkrác]

Mě to taky vadí tím spíš, že pro to není naprosto žádný důvod. Vše, co Qt dělá preprocesorem, tak C++ zvládně přímo.

Navíc foreach podporuje každý standardní překladač C++ už minimálně osm let, na to není potřeba žádné Qt4.

Prostě kdysi dávno jsem Qt odepsal ze dvou důvodů: naprosto zbytečný preprocessor na věci, které by nativně zvládlo C++ samo a druhým důvodem je pro mě nepřijatelná licence

[paskma]

Jenomže oni s tím v Trolltechu začali v době, kdy C++ bylo někde jinde. Proto mají svoje stringy, kontejnery atd.

Jaký foreach v std c++? Nějaké makro ze STL?

[#Tom]

Třeba tady: http://www.cppreference.com.

[Miloslav Ponkrác]

Co svět světem stojí a od té doby, co existuje norma jazyka C++, tak je tam všechno, co Trolltech řeší svými proprietárními řešeními. Od doby první normy jazyka C++ je tam vše, na co Trolltech používá svoje stringy, kontejnery a vše, co řeší preprocessorem. A řešení, které je ve standardu C++ je zatím vždycky o několik tříd lepší, než to, co vymyslel Trolltech, zvláště co se kontejnerů týká.

A to, že Trolltech začal vyvíjet v programovacím jazyce C++ v době, kdy ten programovací jazyk ještě neměl žádný standard považuji za jeho blbost. Já bych to rozhodně u velkého projektu neudělal. Toť celé.

[paskma]

A to, že Trolltech začal vyvíjet v programovacím jazyce C++ v době, kdy ten programovací jazyk ještě neměl žádný standard považuji za jeho blbost. Já bych to rozhodně u velkého projektu neudělal. Toť celé.

I C++ bez STL je pořád výkonnější, než plain C. Na 99% věcí stačí "C s třídami" - omezení viditelnosti, virtuální metody a sem tam jednoduchá dědičnost.

Tedy, abys mě netahal za slovíčka. Dobré kontejnery se hodí vždy, do je jasné. Ale i bez nich se to dá zkousnout, protože si je můžeš napsat. V C si je nenapíšeš, protože tam není zapouzdření.

[Miloslav Ponkrác]

No, ono je to tak, že v té době, kdy Trolltech začínal, existovalo poměrně dost výkonných objektově orientovaných jazyků, které byly plně standardizovány, a které jsou stejně výkonné, ba i výkonnější, než tehdejší ořezané C++. Dnešní C++ je mnohonásobně mocnější, než C++, co bylo tenkrát.

Navíc považuji od Trolltechu volbu C++ za pokrytectví, protože oni neustále šilhali po objektově orientovaném programovacím jazyce Objective C, které v té době bylo plně vyzrálé (díky NextStepu), a které mohli velmi úspěšně použít. Nakonec stejně oni svým preprocessorem nedělají nic jiného, než napodobují věci z Objective C, což také nakonec ve svých materiálech plně přiznávají. Proč tedy nepoužili rovnou Objective C? Objective C je velmi výkonný jazyk a na účely, kde ho Trolltechové používají i výkonnější, než C++. Na Objective C je založeno nejpromyšlenější programovací prostředí, které znám, a to je Cocoa.

Dále bych zmínil další plně hotové objektově orientované jazyky, které mohl Trolltech použít, jako je třeba Simula, Smalltalk a řada dalších.

Já jen prostě říkám, že zvolit si nehotový jazyk na velký projekt je prostě blbost. Troltech si zvolil tehdy ještě nedozrálé C++, pak ho zprznil svým preprocessorem, aby doplnil vlastnosti, které už v hotovém C++ jsou. Pak doplnil řadu tříd, které nakonec v hotovém C++ taky jsou. A výsledkem je jeden velký bordel s tím, že pseudořešení Trolltechu jsou horší, než to, co je standardně v C++.

[paskma]

Nejsi ty náhodou alter ego Ondry Čady? Jo, ObjC je dost dobrý pragmatický jazyk. S tím naprosto souhlasím. Jsou tam pořádné objekty a je to ďábelsky rychlé. Ale fakt nevím, jak to tehdy bylo s překladačem. GCC to tehdy možná neuměl a asi byl nějaký překladač v NeXTStepu, jenže jaká licence? Nevím. Standard (ECMA/ANSI/ISO) nevím jestli to má dnes, ale určitě to má silný de-facto standard.

První OO programovací jazyk s de jure standardem byla Ada95, to jen tak na okraj .

Ale se Smalltalkem nebo Simulou na mě nechoď. Všechny pokusy propašovat do Unixu non-C jazyky skončily špatně. ST je filozoficky namáklý, ale na normální věci se nehodí. Simulu moc neznám - představuju si to jako něco pascaloidního s objektama. Kdyby se takhle rozhodli, ani jeden z nás Trolltech nezná, takový můj soud.

Rozhodnuti Trolltechu bylo pragmatické. Teď z toho mají nějaké dědictví, ale není to žádná katastrofa. Spousta programátorů si Qt pochvaluje jako skvělý framework.

[Miloslav Ponkrác]

Proboha! Chlape! Ada přidala objekty až v roce 1995!!! A to prosím pěkně Ada je jazyk, pokud se nemýlím, kde nejdříve vznikne standard a až pak se implementuje, takže v roce 1995 co je mi známo žádný Ada překladač s podporou OOP neexistoval!

Jak to, že všechny non-C jazyky skončily v Unixu špatně? Já naopak pozoruju naprostý opak. Já v Unixu pozoruju takový přehršel jazyků, a většinou hodně vzdálených od C, až je mě samotnému z toho špatně. A nežijou si v Unixu špatně a prospívají. Naopak! Čím dál více projektů se od C/C++ vzdaluje, a hlavně čím dál více úspěšných projektů.

Můj soud je takový, že za dobrým grafickým frameworkem půjsou lidi do jakéhokoli rozumného jazyka. Vidím to v praxi dnes a denně, kdy se programovací jazyk volí převážně podle toho, jaká je k němu grafická knihovna. Vždyť se stačí podívat! Kolik lidí třeba používá přiblblý Pascal jen proto, že existují graficky namáklé Delphi! A proč myslíte, že Microsoft měl úspěch se svým Visual Basicem? A proč si myslíte, že lidé na Macovi se snaží programovat v Objective C?

Rozhodnutí Trolltechu bylo pragmatické, ok. Jenom je potřeba, aby se prostě říkalo nahlas, jaké prasárny z toho dneska jsou. Pro mě jsou to prasárny nezkousnutelné. Jediné, proti čemu protestuji, je balení argumentů typu z nouze ctnost do hezkého hávu, proč je to geniální, jak mnohdy kolem Qt slyším. Je třeba prostě říkat pravdu.

[paskma]

To o té Adě tvrdí její autoři. Chtěl jsem na tom demonstrovat že s de jure standardy OO jazyků to není tak jednoduché. Bylo něco před ISO C++ z roku 1997? Jen ISO C 90.

Ano, v současné době letí věci jako Python a Ruby. A nežijou si špatně. Ale vem si, kolik lidí tě bude přesvědčovat, že Java/C# jsou děsně pomalé. Dokonce někdo tvrdí, že Delphi jsou pomalé. Dělat před deseti lety grafický toolkit v něčem jiném než C/++ by byla cesta do pekel. Maximálně tak to ObjC.

Všechny Pythoňácké programy, co znám používají GTK nebo Qt, tedy nativní, knihovny. Stejně tak C# s Gtk#. Javácký Swing má dodnes problémy, i když se to lepší. Eclipse Swing nepoužívá a možná je to jeden z faktorů úspěchu.

[Miloslav Ponkrác]

No tak to se shodneme. Všechny, absolutně všechny progrmaovací jazyky stejně používají knihovny psané v C, nebo asm. Je jedno, jaký programovací jazyk si vezmeme. Úlohou Céčka není stejně nic jiného, než zastoupit roli přenositelného assembleru.

Ono co se týká de jure standardů, ono jich moc není. Většina jazyků měla v té době standard de facto. Možná bychom došli i k závěru, že mezi jedním z prvních OOP jazyků byl taky Fortran, který kdysi OOP taky adoptoval, ale bohužel netuším kdy.

Java je až moc rychlá až mě to děsí a C# je ještě o něco rychlejší. Ale vzpomínám se, že tak kolem roku 1990 spousta programátorů odmítala C++, protože je pomalé.

Eclipse používá SWT a já beru SWT jako dočasnou improvizaci, která doufám vypadne ze hry úplně.

Dnešní Swing už je rychlostně úplně jinde a je s SWT zhruba srovnatelný. Navíc Swing je podstatně lépe navržen a já osobně jsem se rozhodl používat výhradně Swing. Ty prasárny uvnitř ála SWT mi můžou být ukradené.

Naštěstí Java, ač ten jazyk příliš nemiluji, má jakousi přirozenou schopnost samočištění, kdy prasárny zůstávají pouze jako vzpomínka v historii. Proto si myslím, že i výstřelek IBM, který bych nazval dočasným řešením ála SWT bude taky brzy jen zkomírat. Osobně si myslím, že s touto schopností samočištění bude jednou Java naprosto bezkonkurenční a velice schopná.

[Kyosuke]

První OO programovací jazyk s de jure standardem byla Ada95, to jen tak na okraj .

Ne, to byl ANSI Common Lisp z roku 1994.

[Miloslav Ponkrác]

Ano, přesně tak. Foreach patří mazi standardní algoritmy STL a vsadím se, že možnosti standardních algoritmů STL mnohonásobně překonávají pseudořešení, které nabízí Trolltech v Qt4.

Hrozně by mě zajímalo, čím Rezza obhájí prasácké praktiky Trolltechu. Mohl by se vytasit, co ještě Qt4 údajně v preprocessoru má a není v C++. Myslím si, že by to prostě neustál, v C++ je všechno, co Trolltech prasí svých preprocessorem.

[Lubos Lunak]

Extra body za to Objective C v jednom komentari, to me docela pobavilo, jinak by vsechny tyhle blaboly o Qt ani nestalo za to cist, stejne nesmysly se rikaly uz pekne davno (a stejne jsou od lidi, kteri Qt evidentne nikdy v praxi nepouzili, z tech, kteri ho pouzili/pouzivaji si jich totiz na Qt stezuje hodne malo). Takze vlastne ani nema smysl se tu snazit, protoze tohle evidentne nikdy nevymre, no ale nemam zrovna co delat, tak proc ne.

- "Na rozdíl od Qt je to čisté C++, žádný preprocesor a podobné nechutnosti." - autorovi evidentne usel takovy maly detail, totiz se soucasti cisteho C++ je preprocesor a kazdy jeden normalni program v C++ preprocesor nutne potrebuje. Navic, g++ neimplementuje zadna rozsireni extra pro Qt, takze jestli to prelozi Qt, tak Qt evidentne je take C++. (BTW, kdo to nahodou nevi, moc neni preprocesor.)

- "Vše, co Qt dělá preprocesorem, tak C++ zvládně přímo." - Aaaha. A jak ze se tedy v primo C++ ziska seznam properties objektu, ktere jde editovat v designeru? Navic, i kdyz nektere veci mozna jde delat primo v C++, je to vetsinou dost hrozne. Treba ten for_each priklad z http://www.cppreference.com je proste ohavnost. Extra struct napsana nekde mimo? Teoreticky uzasna vec, tak cista, tak standardni, tak necitelna, tak komplikovana.

- "A řešení, které je ve standardu C++ je zatím vždycky o několik tříd lepší, než to, co vymyslel Trolltech," - to me pobavilo. Ne ze by tedy nutne vsechno v Qt bylo lepsi, ale tohle je nesmysl. Neco je v Qt proto, ze je to lepsi, neco tam je z duvodu zpetne kompatibility, tak jako tak to tam ma nebo melo byt. A dovolim si citaci z gtkmm FAQ: "gtkmm has Glib::ustring which has almost the same interface as std::string. This new type exists because the C++ standard does not support UTF8-encoded strings."

- "A to, že Trolltech začal vyvíjet v programovacím jazyce C++ v době, kdy ten programovací jazyk ještě neměl žádný standard považuji za jeho blbost. Já bych to rozhodně u velkého projektu neudělal. Toť celé." - No jo, holt ne kazdy na tom dokaze vydelat miliony.

- "Navíc považuji od Trolltechu volbu C++ za pokrytectví, protože oni neustále šilhali po objektově orientovaném programovacím jazyce Objective C" - to vazne nevim, ale budu se na to muset zeptat. Ne proto, ze bych tomu veril, ale protoze mi neco rika, ze je to dobre pobavi.

Jinak, oficialni vyjadreni TT o ze, ze (a proc) asi nikdy nezahodi moc na ukor sablon atd. je tady: http://doc.trolltech.com/3.0/templates.html

No nic, ale ja vam to gtkmm nakonec neberu. Kdyz to nekoho tak bavi ...

[paskma]

A co je moc, když ne preprocesor?

[paskma]

A k tomu ustringu. C++ nepodporuje utf-8, ale podporuje UCS-2 - wchar, wstring. Ale nikdy jsem s tím nedělal

[Miloslav Ponkrác]

Já se vsadím, že C++ ten utf8 nakonec taky podporuje, byť nepřímo pomocí funkcí z knihovny locales. Tuším to tam, bohužel locales je jediná část C++ kde plavu, protože k tomu neexistují žádné slušnější zdroje.

[Lubos Lunak]

> A co je moc, když ne preprocesor?

Preprocesor je neco, co _musi_ upravit data tak, aby je slo pouzit pro dalsi krok. Napr. v C++ jsou kroky .cpp -> C++ preprocesor -> .ii -> C++ prekladac -> .o . Bez pouziti C++ preprocesoru by neslo .cpp primo poslat C++ prekladaci, ze to tak vypada je jen proto, ze g++ tyhle kroky dela automaticky. Zdrojove kody v Qt jde dat primo g++, tudiz neni potreba zadny preprocesor.

Ja nevim, jak se presne rika tomu, co je moc, ale nazval bych to treba generator kodu. Funguje to na stejnem principu jako treba doxygen nebo ruzne IDL prekladace. Stejne jako doxygen analyzuje kod a dalsi znacky (ktere ma doxygen v komentarich) a z toho generuje popis toho kodu a dokumentaci, tak moc analyzuje kod a dalsi znacky (ktere jsou povetsinou hlavne kvuli citelnosti primo v kodu a protoze jsou vytvorene pomoci #define, tak je to korektni C++ kod) a generuje z toho dalsi kod. Ten kod si jde normalne prohlednout ve vyslednem .moc souboru. Moc by, striktne vzato, ani nebyl treba, slo by to klidne napsat i rucne, ale uprimne, kdo by to delal?

Veci neznali odpurci Qt si klidne muzou myslet neco o odpurnostech, prasackych resenich a podobne, ale pravda je takova, ze v Qt se to pouziva proto, ze to ten kod vylepsuje. Viz hned prvni cast "Syntax matters" z toho dokumentu, ktery jsem odkazoval. Mozna by to slo udelat v "100% cistem C++" (a co to sakra vlastne je?), ale jestli to bude 10x hur pouzitelne, co z toho?

> A k tomu ustringu. C++ nepodporuje utf-8, ale podporuje UCS-2 - wchar, wstring.

No, to je fakt uzitecny, kdyz prakticky kazdy krome C++ pouziva utf-8.

[#Tom]

UCS-2 je pro uložení a zpracování řetězců lepší, protože se s ním pracuje lépe a rychleji. UTF-8 se ujalo snad jen kvůli zpětné kompatibilitě s dolní polovinou ASCII tabulky.

[aspik]

UCS2?! Jediný horší návrh už mohl být UTF-16, které spojuje nevýhody variabilní velikosti znaku a nekompatibility s ASCII (proto ho asi používá Microsoft).

Smysl má používat UCS4 nebo UTF-8, které dokáží representovat celý rozsah Unicode. První má pevnou velikost znaku, druhé kompatibilitu s ASCII.

[paskma]

Právě jsem se na wikipedii dočetl, že UTF-16 používí ja Java. Celkem překvapení. Takže spousta javovských programů je blbě, protože nepočítá s tím, že může dostat řetězec, který správně nerozebere na pole charů (16bitových).

[Miloslav Ponkrác]

aspik má pravdu, uft16 je snad to nejhorší kódování, co existuje. Java samozřejmě má upravené třídy tak, aby s tím počítala, že některé znaky jsou uloženy nadvakrát a umí s tím pracovat.

pokud chcete dělat programy, které nebudou mít problémy a nebudou muset šachovat s tím, že některé znaky jsou uloženy ve víc položkách, pak jedině pole, kde znak má 4 bajty, nic jiného. naštěstí C++ je jeden z mála jazyků, kde je podporován i takový string.

[paskma]

C++ podporuje všechno, stejně jak assembler Jestli jestli považujete možnost udělat pole intů64 a udělat kolem toho třídu za podporu nějakého standardu, ok

Prostě unicode bylo původně navrženo jako 16bitové a basta. A Java je podle toho. Pak vyšla nová norma unicode 2.0 a najedou bylo 16 bitů málo. Takže se to musí i v té Javě ad hoc ošetřovat a jsme tam, kde jsme byli. Naštěstí za hranicí 16 bitů je jen Gótština a vlastní jména z japonštiny a čínštiny. Takže to vyžadují jen programy pro tamější státní správy.

Asi nejlepší řešení je kódovat řetězce UTF-8 (zpětně kompatibilní, úsporné) a jednotlivé znaky považovat za 32bitové.

[Miloslav Ponkrác]

Nikoli, nepodceňujte C++. Zapomínáte, že v STL existuje šablona basic_string, které je v zásadě jedno, co jí určíte za typ jako znak. Takže stačí, když vyrobíte něco jako char_traits pro 4 bajtový znak, což je velmi jednoduchá záležitost a zbytek, to jest implementaci všech metod třídy pro 4 bajtový řetězec zařídí šablona basic_string, aniž byste musel hnout prstem. Ostatně naprosto stejným způsobem v STL jsou implementovány třídy string a wstring.

Co se týká Unicode, tak jasně, že se začínalo na 16 bitech. Dnes je určeno, že kódování Unicode potřebuje 21 bitů. Nad hranicí 16 bitů je toho docela dost. I když uznávám, že pro naše potřeby v podstatě skoro vždycky dostačuje osmibitové kódování.

UTF-8 zrovna nutně úsporné být nemusí, ale má obrovskou výhodu, že je přenositelné a nejsou tam žádné problémy s BOM znaky, apod.. UTF-8 je dobrý jako přenositelný formát, ale na zpracování to není nic moc pěkného.

[paskma]

No jasně. Jenže já trvám na tom, že podpora chytrým kontejnerem na znaky není dostatečná.

Ono to v C++ s takovým přístupem dopadne tak, že se v programu míchají hromady řetězců. Určitě je občas potřeba jednoduchý ukazatel pro nějaké funkce a pak něco z CString (MFC), QString, AnsiString (Borland), ustring (gtkmm), a navíc skoro každý programátor si v životě nějakou tu třídu na řetězce napsal. Já v 17ti stringM . No a některé ty třídy si teď představte v x verzích pro různé kódování unicode. A aby se v tom vyznalo prase.

Souhlasím s vámi, že v C++ je možné pracovat s jakýmkoliv řetězcem a kódováním, ale ptám se kdo o to stojí?

V Javě to bylo k plné spokojenosti. Do Unicode2

Cílový stav je pro mě 32bitový char a k němu nějak rozumně kódované řetězce, utf-8 nebo utf-16, když mě popotahujete za to, že utf-8 není pro tradiční čínštinu úsporné.

[Miloslav Ponkrác]

Já s Vámi naprosto souhlasím. Mám úplně stejný názor.

Univerzální kontejner na znaky, který si řetězce představuje jako pouhé pole znaků trochu pokulhává za skutečným použitím. Řetězce se ve skutečnosti takto synteticky netváří.

Bohužel tříd na řetězce je mnoho a já sám jsem asi dvě takové napsal.

Problém je, že to není jenom problém C++, protože spousta jazyků překotně zavedla 16-ti bitové řetězce s tím, že to bude krásně čisté. Upřímně řečeno, už tehdy jsem věděl, že je to jenom chiméra, protože už jsem měl zkušenosti, že každé šetření bajtíkama vede jenom k problémům. A vyhradit pro znak jenom dva bajty namísto jednoho je jasný případ nemístného šetření bajtíkama.

Já osobně si hodlám napsat třídu pro 32 bitový znak a jet časem jenom v tom. Ale díky Unicode je v tom taky bordel, protože některé znaky jsou vyhrazeny pro různé prznící přepínače pro utf16 a další kódování.

Jinak jsem rád, že zohledňujete Číňany ve zvolení znakové sady

[paskma]

Ok, jsem rád, že se shodem.

Jenom taková poznámka. Že Java podlehla vábení 16bitového charu je pochopitelné. Že je stejná chyba v C# už je docela velká hloupost. A Anders Hejlsberg by zasloužil...

Jak pracovat s Gótským jazykem:

http://java.sun.com/developer/technicalArticles/Intl/Supplementary/

[Miloslav Ponkrác]

Javu taky chápu. A ostatně C# taky chápu, protože Microsoft jenom málokdy přemýšlí. Ve skutečnosti Microsoft jen okopíroval Javu a Win API a nic z toho mu nenapovědělo, že by se hodilo 32bitů na znak. A navíc by Microsoft musel řešit problém, kdy mnoho funkcí řetězců by nebyl pouhý wrapper nad Win API, což by už jaksi bylo trochu víc práce a tak se to neudělalo. Já když hodnotím Microsoft, tak nejlépe udělal ty věci, které prostě obšlehl. Někdy to dokázal i mírně zlepšit.

A Hejlsberg? Co čekáte od člověka, který navrhnul Delphi a vše postavil na osmibitovém stringu?

[paskma]

První Delphi běžely pod Windows 3.11, snad na 4 a určitě na 8 MB paměti. Internet "neexistoval" a 32bitový char bylo moc silné kafe i na scifi

Na Hejlsberga mi nešahejte

[Miloslav Ponkrác]

Já bych řekl, že první Delphi je tak maximum, na co Hejlsberg v Borlandu mohl šáhnout. V roce 1996 totiž Borland opustil.

Pak taky napsal překladač Turbo Pascalu, který Borland úspěšně prodával a tím se zasloužil o vstaní z hrobu tohoto strašného programovacího jazyka.

Pak měl nějaké aktivity kolem J++ a WFC, což naštěstí Sun sprovodil ze světa.

A co se týká .NETu, tak tam podle mého ani řetězce moc ovlivnit nemohl, protože pokud mám dobré informace, tak jeho hlavní aktivity se točily kolem C#. Tím pádem měl pevně určené, co bude .NET framework mít a podle toho musel dělat C#.

[#Tom]

S Turbo Pascalem jsem se začal učit programovat na PC. Ten překladač jsem měl velmi rád, byl hodně rychlý i na tehdejších pomalých 384 a 486, které jsem mohl používat. S kvalitou kódu to bylo horší, ale nebýt jí, asi bych se nenaučil trošku programovat v asembleru.

[Miloslav Ponkrác]

Já jsem v Turbo Pascalu taky dělal. Koneckonců Pascal byl první solidní jazyk, který jsem se naučil (nepočítám-li nějaké ty assemblery, Basicy, Fortrany atd.). Pascal mě naučil prvním základům slušného programování a jsem tomu jazyku zato dodnes vděčný. Také jsem v Pascalu nadšeně dva roky programoval. Vše skončilo v okamžiku, kdy se mi do ruky dostala knížka o jazyce C. Půl hodiny poté, co jsem knížku otevřel jsem věděl, že už v Pascalu dobrovolně nenapíšu ani čárku.

Pascal je dobrý jazyk na výuku, a konenckonců s tímto účelem jej Wirth vytvořil. Na solidní programování podle mě není a nebýt Borlandu, tak tu Pascal nemáme. Bohužel, čas od času jsem nucen něco malého stvořit v Delphi a nad Pascalem skřípu zubama. Kromě toho některé programy vytvořené v Delphi používají skriptovací jazyk, který je samozřejmě nápadně podobný Pascalu. Takže se skřípěním zubů vytvářím Pascal skripty v jinak výborném instalátoru pro Windows zvaném InnoSetup.

Podle mě jediné jazyky s Pascaloidní syntaxí, které za něco stojí jsou Simula a Ada.

[#Tom]

Já jsem se s Céčkem setkal asi rok po Pascalu (1994/1995, už si to nepamatuju), ale to bylo také od Borlandu a zrovna moc mi nesedlo. Sice jsem se v něm něco naučil, ale nestálo to skoro za nic. Pascal jsem navždy opustil až v prosinci 1999, kdy jsem našel DJGPP, které bylo 32bitové, jelo v chráněném režimu a umožňovalo se v paměti celkem roztahovat. Sice se hojně používalo i nějaké Watcom C/C++, které jsem dlouho hledal, ale přes velkou snahu jsem jej nesehnal. Škoda, že jsem DJGPP nepoznal dřív...

[Miloslav Ponkrác]

DJGPP je asi nejlepší překladač pro DOS, co jsem zažil, i když moc jsem v něm nedělal. Svoje první programy jsem dělal v Borlandu, dokonce chvíli i ve Watcomu (to když jsem překládal pro Novell Netware). Ale možná mi to neuvěříte, spokojený jsem byl až s překladačem od Microsoftu. To jsem měl poprvé pocit, že mám před sebou dobrý kompilátor (samozřejmě nesrovnávám s DJGPP, protože v té době co jsem začínal, tak DJGPP ještě neexistoval).

No, takže jsem řadu let dělal v C, pak v C++, to když přišlo Borland C++ 1.0, dodnes mám zdrojáky, ale už je nepřeložím, protože mezitím byl jazyk C++ tak překopán, že tehdejší C++ programy jsou prostě pro dnešní kompilátory nepřeložitelné.

Naštěstí dnes už je situace jiná. Dobrých kompilátorů je spousty, stačí jen vybírat. GCC, Intel, Microsoft, Digital Mars, člověk neví, co si má vybrat dřív. Tehdy neexistoval kompilátor, nebo program zdarma, všechno bylo za peníze a můj první legálně koupený program byl právě kompilátor Céčka pro DOS zhruba za 1000 Kč, což tehdy byly velké peníze.

[#Tom]

Jak už jsem napsal, Watcom jsem nikdy nepoznal, ale pochvala Microsoftu za jeho C mě nijak nepřekvapuje. Nevím, jak starší verze, ale Borland C++ 3.0 mě moc nenadchlo. V C jsem toho opravdu moc neuměl, ale když překladač při zpracování mých nedobře napsaných programů padal, nebyl jsem si zcela jist, jestli je to chyba moje, nebo onoho kompilátoru (bcc). Pokud k tomu dělal MS také lepší kód, byla asi spokojenost na místě.

GCC mi spadlo jenom jednou (3.4.0) u nějaké zprasené šablony.

[Miloslav Ponkrác]

Borlandské Céčko bylo hrozně chybové. Občas jsem měl pocit, že neprogramuju, ale dělám betatestera Borlandu.

[Miloslav Ponkrác]

Napr. v C++ jsou kroky .cpp -> C++ preprocesor -> .ii -> C++ prekladac -> .o

Naprostá většina překladačů, se kterými jsem se setkal fungovala bez toho mezikroku mezi .cpp a .ii, většinou kompilátor prostě zpracovával zdroják i s příkazy preprocessoru rovnou do objektového kódu. Ono když chcete mít rychle kompilující překladač, tak je to jedna z cest, která se používá.

Zdrojove kody v Qt jde dat primo g++, tudiz neni potreba zadny preprocesor.

Mohu se zeptat, zda to samé mohu udělat i v prostředí Visual C++, které převážně používám? U standardního preprocessoru s tím nemám žádný problém.

Qt se to pouziva proto, ze to ten kod vylepsuje

Ale v podstatě pro každý problém lze napsat speciální preprocessor, který bude mít určitě mírně čitelnější kód, protože bude obsahovat speciálosti. Ale strašně nerad bych se dožil okamžiku, kdy každá knihovna, kterou budu používat bude vyžadovat speciální preprocessor.

No, to je fakt uzitecny, kdyz prakticky kazdy krome C++ pouziva utf-8.

Běžný přístup je, že utf8 je vstupní a výstupní formát, ale data se zpracovávají vnitřně v utf16, nebo v utf32, což je ve standardní knihovně C++ obojí plně podporováno. A konverzi mezi utf8 a formáty dalšími lze pomocí standardní knihovny C++ zajistit.

[Lubos Lunak]

> Naprostá většina překladačů, se kterými jsem se setkal fungovala bez toho mezikroku mezi .cpp a .ii, většinou kompilátor prostě zpracovával zdroják i s příkazy preprocessoru rovnou do objektového kódu. Ono když chcete mít rychle kompilující překladač, tak je to jedna z cest, která se používá.

Dalsi hezky pokus.

- je to naprosto irrelevantni pro diskuzi

- ano, je to spravne, dokonce i gcc to tak dela - je tohle snaha presvedcit ostatni, ze autor vsechno vi a vsechno zna?

- i kdyz dnes zadny prekladac normalne ten .cpp -> .ii krok nedela, dela se porad interne, protoze se proste musi delat

>> Zdrojove kody v Qt jde dat primo g++, tudiz neni potreba zadny preprocesor.

(BTW, tady jsem samozrejme myslel zadny _dalsi_ preprocesor. Krom toho z C++.)

> Mohu se zeptat, zda to samé mohu udělat i v prostředí Visual C++, které převážně používám? U standardního preprocessoru s tím nemám žádný problém.

Aha. Samozrejme ze Qt jde normalne prelozit i v Visual C++.

A, jestli to dobre chapu, tak tady kritizuje Qt nekdo, kdo se nikdy neco napsane pomoci Qt ani neobtezoval prelozit. No, na druhou stranu, nejspis to alespon drzi normu se vsemi ostatnimi kritiky Qt.

> Ale v podstatě pro každý problém lze napsat speciální preprocessor, který bude mít určitě mírně čitelnější kód, protože bude obsahovat speciálosti. Ale strašně nerad bych se dožil okamžiku, kdy každá knihovna, kterou budu používat bude vyžadovat speciální preprocessor.

Jak uz jsem rekl, moc neni preprocesor.

[Miloslav Ponkrác]

je tohle snaha presvedcit ostatni, ze autor vsechno vi a vsechno zna?

Pane, co kdybyste začal diskutovat trochu korektně? Napsal jsem já o Vás nějaké osobní hodnocení? Začal jsem se o Vás otírat jako o člověka? Nikoliv, zatím jsem pouze argumentoval o faktech, ale Vy začínáte pomalu rozdávat osobní podpásovky. To dělají lidé, kteří se necítí jistí v kramflecích, že začínají nenapádně shazovat osobu, která diskutuje.

i kdyz dnes zadny prekladac normalne ten .cpp -> .ii krok nedela, dela se porad interne, protoze se proste musi delat

Ne, věřte mi, že naprostá většina kompilátorů prostě najednou bere jak příkazy makroprocesoru, tak příkazy C/C++. Pro většinu kompilátorů je to jedno a totéž. Jinak řečeno, je to tak zaintegrováno do kompilátorů, že už snad ani o preprocessingu mluvit nedá.

A když už jsme u toho interního provádění, v tom případě takové gcc interně dělá asi 20 různých preprocessingů, protože každý krok ve zpracování zdrojáku lze považovat za preprocessing, budeme-li mluvit o interních věcech.

Aha. Samozrejme ze Qt jde normalne prelozit i v Visual C++.

Ano, přeložit to jde, ale jaké jsou s tím oplétačky, že? Takové vizuální prostředí Visual Studia jaksi příliš nepočítá s tím, že by zdrojáky C++ měl prohnat přes nějaký moc, že? Ne, že by to něšlo zařídit, ale jsou s tím problémy a polovina výhod vizuálního prostředí ve Visual C++ se ztrácí.

Jak uz jsem rekl, moc neni preprocesor.

Samozřejmě, moc je čínský bůh srandy, já zapomněl.

[Miloslav Ponkrác]

Já zkusím trochu zareagovat.

autorovi evidentne usel takovy maly detail, totiz se soucasti cisteho C++ je preprocesor

Ne, autorovi to neušlo, ale preprocessor, který je součástí čisté C++ je jednak standardní, takže všechny vývojové a ladící nástroje pro C/C++ na celém světě s ním přirozeně počítají. Dále tento preprocessor řeší věci, které nejsou zajistit standardními prostředky C/C++, takže je navíc užitečný.

Aaaha. A jak ze se tedy v primo C++ ziska seznam properties objektu, ktere jde editovat v designeru? Navic, i kdyz nektere veci mozna jde delat primo v C++, je to vetsinou dost hrozne. Treba ten for_each priklad z http://www.cppreference.com je proste ohavnost. Extra struct napsana nekde mimo? Teoreticky uzasna vec, tak cista, tak standardni, tak necitelna, tak komplikovana.

Opravdu si myslíte, že nelze naimplemetovat seznam properties bez standardních věcí C++? Já si to nemyslím. for_each se mě osobně velice líbí a nevím, co je na tom nepřehledného, nečitelného, komplikovaného, atd..

A řešení, které je ve standardu C++ je zatím vždycky o několik tříd lepší

O tom jsem naprosto přesvědčen. Zatím vše, co je ve standardu C++, zejména kontejnery jsou podle mě daleko více na výši. Ale vzhledem k tomu, že jste nepodal žádný argument, nelze s Vámi o tom konstruktivně diskutovat.

gtkmm has Glib::ustring which has almost the same interface as std::string. This new type exists because the C++ standard does not support UTF8-encoded strings."

No a co? Můžu Vám třeba prozradit sladké tajemství, že takové C++ třeba nepodporuje ani třeba octoniony, což je určitě hrozná vizitka pro standardní knihovnu C++.

Mě by třeba zajímalo, kdy Qt knihovna opraví chybné zamykání objektů v mnoha třídách, zejména ve třídě QString. Když jsem se díval do zdrojáků Qt4, tak jsem zjistil, že pro multithredové programování to bude dělat bordel a Trolltech asi neumí programovat. Zajímavé je, že ve standardní knihovnách C++ je zamykání napsáno správně.

Ne proto, ze bych tomu veril, ale protoze mi neco rika, ze je to dobre pobaví

Ale no tak. O tom Objective C to přímo píšou ve zdůvodnění, proč použili preprocessor. Najdete to přímo na webových stránkách Trolltechu.

Jinak, oficialni vyjadreni TT o ze, ze (a proc) asi nikdy nezahodi moc na ukor sablon

K tomu jsem se vyjadřoval už v jiné diskusi. Stručně: V C++ neexistují jenom šablony, a některé věci se efektivněji řeší bez šablon. Konkrétně náhradu moc bych si já osobně spíše představoval prostředky C++, které se šablon netýkají. Bohužel Trolltech by možná měl standard C++ trochu nastudovat, aby alespoň trochu zběžně poznal programovací jazyk, který používá.

No nic, ale ja vam to gtkmm nakonec neberu. Kdyz to nekoho tak bavi ...

Neexistuje jenom gtkmm

[Lubos Lunak]

(Ja snad jeste prestanu myslet na to, ze na me jde asi chripka. Tohle me zacina bavit a stejne nic lepsiho delat nemuzu.)

> [Vicemene nicnerikajici zblebt o C++ preprocesoru.]

...

> Opravdu si myslíte, že nelze naimplemetovat seznam properties bez standardních věcí C++? Já si to nemyslím.

No, tak tohle me presvedcilo, ted uz verim. Ne, moment, ja vlastne myslel spis "prijatelne jednoduse implementovat", ne jen "implementovat". Jako treba ze se nekam pripise jednoduchy radek, nebo tak neco.

> for_each se mě osobně velice líbí a nevím, co je na tom nepřehledného, nečitelného, komplikovaného, atd..

Kde zacit? Takze
- telo for_each je napsano nekde uplne jinde nez ten samotny for_each
- ten functor pro for_each je na nekolik radku, protoze to je struct, ktery obsahuje operator - viz. treba ten priklad z cppreference.com - pricitani jednicky na 5 radku???
- coz samo o sobe je odpoved na to, co je na tom komplikovaneho, necitelneho a narocneho
- pro cokoliv narocnejsiho clovek si bud ten functor pro for_each musi napsat sam, nebo musi pouzivat podivne konstrukce jako bind2nd

A nebo, proc rovnou ne priklad, nejake hypoteticke cokoliv, treba provedeni operace foo u vsech objektu, ktere ji potrebuji. V Qt pomoci foreach (nebo Q_FOREACH, jak kdo chce):

foreach( Object* object, objects )
    if( object->needsFoo())
        object->foo();

Tak, ted STL, podle toho navodu na cppreference.com :

struct foo_if_needed : public unary_function<Object*, void>
{
    void operator() (Object* object)
    {
        if( object->needsFoo())
            object->foo();
    }
};

 ...

 for_each( objects.begin(), objects.end(), foo_if_needed );

No neni to nadhera? Kdybych se snad spletl a slo to udelat jeste lepe, sem s tim.

> A řešení, které je ve standardu C++ je zatím vždycky o několik tříd lepší > O tom jsem naprosto přesvědčen. Zatím vše, co je ve standardu C++, zejména kontejnery jsou podle mě daleko více na výši. Ale vzhledem k tomu, že jste nepodal žádný argument, nelze s Vámi o tom konstruktivně diskutovat.

(Mimochodem, dalsi hezky priklad toho, ze kdyby bylo nejhur, nekdo se tady vzdycky dokaze uzivit alespon v PR.)

Jako argument jsem uvedl treba to, ze Gtkmm pouziva vlastni tridu pro string, protoze tomu v STL (minimalne podle nich) chybi funcionalita. Schvalne jsem jenom citoval a schvalne jsem si vybral projekt, ktery je primo vysazeny na to, ze vsechno dela "spravne" podle C++. To, ze je tady nekdo ochotny se vsadit, ze to preci jen nekde v tom C++ je, je sice hezke, ale to je tak vsechno. Bud to tam tedy nekde je, ale Gtkmm vyvojari to tam, pres vsechnu jejich (docela bych hadal velkou) snahu nenasli a tak to asi nejde snadno najit, nebo to tam mozna je, ale nejde to v praxi vlastne snadno pouzit, no a nebo to tam neni. At uz je to jakkoliv, jestli si projekt jako Gtkmm nakonec udelal vlastni tridu pro string, neco s tou v C++ je spatne.

Pokud me moje vzpominky na hodiny matematiky a logiky ze skoly neklamou, na prokazani nepravdivosti tvrzeni "A řešení, které je ve standardu C++ je zatím vždycky o několik tříd lepší", tj. "plati pro vsechny", staci najit jeden priklad, kdy to neplati. Takze to bychom meli.

> No a co? Můžu Vám třeba prozradit sladké tajemství, že takové C++ třeba nepodporuje ani třeba octoniony, což je určitě hrozná vizitka pro standardní knihovnu C++.

Az to bude, treba jako v pripade utf8, na Linuxu pouzivat minimalne kazdy druhy, tak to tak nejspis bude.

> Mě by třeba zajímalo, kdy Qt knihovna opraví chybné zamykání objektů v mnoha třídách, zejména ve třídě QString. Když jsem se díval do zdrojáků Qt4, tak jsem zjistil, že pro multithredové programování to bude dělat bordel a Trolltech asi neumí programovat. Zajímavé je, že ve standardní knihovnách C++ je zamykání napsáno správně.

Jestli to nebude spis tak, ze nekdo asi neumi cist. V dokumetaci pro tridu QString je hned jako treti radek napsano, jak na tom QString ve vztahu k threadum je, dokonce tam je i link na podrobnejsi vysvetleni. Mozna bych mohl i vysvetlit, proc to je jak to je, ale neco mi rika, ze to uz mi za tu srandu nestoji. (Mimochodem, neda mi sem necitovat kousek shora: "Ale vzhledem k tomu, že jste nepodal žádný argument, nelze s Vámi o tom konstruktivně diskutovat.").

> Ale no tak. O tom Objective C to přímo píšou ve zdůvodnění, proč použili preprocessor. Najdete to přímo na webových stránkách Trolltechu.

Zase problem se ctenim. V tom dokumentu, proc pouzili moc (coz je ten dokument, ktery jsem drive linkoval), je slovo 'objective' jen dvakrat. V prvnim pripade se rika, ze staticke typy v C++ maji nektere nevyhody proti tomu vice dynamickemu systemu jako v Objective C. V druhem pripade se rika, ze moc dava Qt flexibilitu podobnou Objective C. Nikde se tam vubec nepise o tom, ze by TrollTech kdy premyslel o pouziti Objective C.

> Bohužel Trolltech by možná měl standard C++ trochu nastudovat, aby alespoň trochu zběžně poznal programovací jazyk, který používá.

No, ono ani ty "pseudoreseni", "zprzneni", "pokrytectvi" a podobne nenastavili latku nijak zvlast vysoko, ale tohle uz je dost ubohy. (Krom toho, spis to plati to lidi, kteri kritizuji neco, o cem vlastne nic nevi.)

[Miloslav Ponkrác]

Ne, moment, ja vlastne myslel spis "prijatelne jednoduse implementovat", ne jen "implementovat". Jako treba ze se nekam pripise jednoduchy radek, nebo tak neco.

V tom případě odvolávám. Ano, připsat někam jednoduše řádek v C++ nelze. V tom případě ale taky provolávám, že moc preprocessor je na houby, protože najdu řadu příkladů, které nemohu vyřešit napsáním na jeden řádek, ani kdybych proháněl přes moc jako šílený.

Já netvrdím, že sem tam něco nejde napsat přes moc tak, aby to nebylo kratší, nebo přehlednější, než v C++, protože každý preprocessor, i ten sebeblbější nějaké výhody v určitých situacích má. Nicméně, kdybyste postupoval tak jako Trolltech třeba v českém jazyce, tak byste zjistil, že některé věty jsou příliš dlouhé a začal byste je nahrazovat preprocessorovými zkratkami. Sice by Vám spousta lidí nerozumělo, ale Vy byste byl spokojený, protože jsem ušetřil pár slov.

O foreach se s Vámi ohledně nutnosti moc preprocessoru bavit nebudu. Odkážu Vás pouze na makro BOOST_FOREACH, které dělá to samé a stejně jednoduše, co Qt4, akorát nepotřebuje žádný moc preprocessor, vystačí si se standardními prostředky jazyka C++. Toto makro se totiž stalo předlohou pro Trolltech a tímto makrem bylo inspirováno to, co je v Qt4. Jenom BOOST_FOREACH je trochu univerzálnější, než to, co vymyslel Trolltech.

Zároveň for_each v STL funguje o poznání jednodušeji, pokud se začneme bavit o kontejnerech v STL.

staci najit jeden priklad, kdy to neplati

Takže zase vedle, viz výše. Čekám další příklad

ktery je primo vysazeny na to, ze vsechno dela "spravne" podle C++

Já jsem nikdy ani v této diskusi gtkmm nehájil a nikdy jsem ho nedával jako vzor, jak se to má správně dělat v C++. Určitě jste ode mě nic takového neslyšel.

Pokud chcete slyšel můj názor, tak skutečnými perlami a diamanty, co se programování v C++ týká jsou některé (zdůrazňuji některé) části projektu boost. gtkmm je podle mě ještě hodně vzadu a má co dohánět.

V dokumetaci pro tridu QString je hned jako treti radek napsano, jak na tom QString ve vztahu k threadum je

No jo, v dokumentaci je psáno... Prostě nedostatky zahrneme do dokumentace a je to. Pro Vaší informaci odstranit tento nedostatek a učinit třídu QString bezpečnou pro thready je záležitostí maximálně půlhodinky opravy zdrojáku, co jsem se díval. Ale Trolltech to raději zdokumentuje. Kdyby měla Qt přijatelnější licenci a nenutila mě do GPL, tak už bych to dávno opravil a zaslal Trolltechu. Ale moje zásada je GPL projekty nechávat napospas osudu...

Ale ten QString jsem zmínil hlavně proto, že jste prostě zmínil jako nedostatek ve standardní knihovně C++ neexistenci třídy pro utf8. Já bych chtěl podotknout, že cokoli je ve standardní knihovně C++ prostě funguje. Za všech okolností, i v threadech. Nemusím číst dokumentaci jen proto, abych zjistil, že někdo stringovou třídu zmrvil, a že funguje jen někdy. To je jeden, a pro mě velmi závažný důvod proč tvrdím, že řešení v C++ je o třídu lepší, než řešení v Qt.

A kdybyste snad chtěl obhajovat QString dále, mohu ještě pohovořit o chování třídy QString vzhledem k výjimkám. To by ale rozhodně Trolltechu čest nedělalo, zatímco ta mrška standardní knihovna C++ s tím zase jako na potvoru nemá žádné problémy.

Na zbytek už reagovat nebudu.

[Lubos Lunak]

Pro ty, kteri maji problemy se ctenim, jeste jednou (poctvrte?) :

MOC NENI PREPROCESOR.

I kdyz, me uz je docela lip, chripka to asi nakonec nebude, takze zase se pujdu venovat necemu uzitecnemu, co ma smysl. Tohle smysl nema, ja si pripadam jako na politicke debate. Na zbytek reagovat se obtezovat nebudu, protoze to jsou bud evidentni snadno dokazatelne nepravdy (tvrzeni, ze foreach v Qt potrebuje moc), vagni obvineni (QString a vyjimky), naivni provolani (vse, co je v C++ knihovne, funguje, za jakychkoliv okolnosti - to me pobavilo) nebo, kdyz uz to asi jinak nejde, ruzna uhnuti od tematu (to je snad v kazdem odstavci, navic nekdy zase spatne, treba druhemu odstavci se myslim rika prejimani cizich slov). Takze je fajn, ze uz se nikomu nebude chtit na nic reagovat.

[#Tom]

Tento můj příspěvek je k ničemu, stejně jako ten bezprostředně nadřazený. Ale možná by nebylo špatné se ujistit, co ono slovo preprocesor znamená.

pre + procedere = před + (vy)konat => (vy)konat před

Označení preprocesor je tedy zcela na místě, i když se od toho běžného preprocesoru poněkud liší.

[Z]

Jenže moc se nevykonává před. Použití moc na nějaký hlavičkový soubor a překlad výsledného souboru je nezávislé na překladu cpp souboru, který patří k tomu. Takže pokud to nahoře je definice preprocesoru, tak pak moc není preprocesor.

[#Tom]

Nemusí to být nutně hlavičkový soubor, ale u většiny programů se využije možost rozdělení kódu do více souborů. Tím se ale nemění nic na tom, že nejprve se preprocesorem moc zpracuje hlavičkový soubor, který se pak spolu s výstupem z moc a zdrojovým kódem, do nějž se vkládá, zpracuje dalším preprocesorem a překladačem.

[Z]

To je jen optimalizace.

            a.cpp -> g++ -> a.o ----------
              ^                          |
              |                          v
a.h -- #include                          ld ----> a.out
 |            |                          ^
 |            v                          |
 -> moc -> a.moc.cpp -> g++ -> a.moc.o ---

Tohle je normální použití moc. Zdrojový soubor se přeloží úplně normálně, bez jakéhokoliv preprocessingu. I a.h se použije úplně normálně, bez jakéhokoliv preprocessingu. Navíc se pomocí moc z a.h vygeneruje a.moc.cpp, který se normálně přeloží a slinkuje. Je tam naprosto evidentně vidět, že:

• a.cpp k překladu vůbec moc nepotřebuje a překládá se to jako normální C++
• a.h se používá přímo, bez jakéhokoliv předzpracování
• výstupem z moc není předzpracovaný a.h, ale nový kód, který moc generuje na základě a.h - tj. není to žádný preprocessing, není to žádné zpracování a.h, ale je to generování dalšího kódu
• pořadí použití moc vzhledem k překladu a.cpp není určeno, takže zase není nutné ho pouštět předem

Co je na tom tak těžkého pochopit? Kde je tam něco, co vypadá jen trochu jako preprocesor?

Vkládání kódu vygenerovaného pomocí moc přímo do a.cpp je jen optimalizace.

                    a.cpp -> g++ -> a.o ------ ld ----> a.out
                    ^   ^
                    |   |
a.h -- #include -----   |
 |            |         |
 |            v         |
 -> moc -> a.moc -> #include

Je to optimalizace jen v tom, že se volá g++ jen jednou místo dvakrát, protože g++ je pomalé. Je to stejné, jako kdyby bylo a.cpp a b.cpp a místo překladu obou by a.cpp udělalo #include "b.cpp" a g++ by se volalo jen na a.cpp (a tím automaticky i na b.cpp). Nic to nemění na tom, že princip je ten obrázek nahoře a tam se moc jako preprocesor nechová.

A kdyby ještě pořád s tím někdo měl náhodou problém, tak poradí Wikipedia: In computer science, a preprocessor is a program that takes source code and performs transformations on it, before the step of compilation or interpretation.

Moc nedělá transformace a.h, a.h se používá přímo, bez moc. Stejně tak se a.cpp používá přímo, bez nějakého předchozího kroku.

[#Tom]

Řekl bych, že ta definice z wikipedie moc pěkně vystihuje, ale je mi jasné, že je naprostá ztráta času to rozebírat nějak dál.

[Miloslav Ponkrác]

MOC JE PREPROCESSOR

To že nazvete klokana opicí neznamená, že to klokan není.

Já nevím, jestli foreach potřebuje moc, jen tvrdím, že elegantní foreach lze dokázat pomocí standardních prostředků C++. QString a výjimky nejsou vágní obvinění. Vše, co je v knihovně C++ funguje o 100% lépe, než obdobné třídy v Qt.

Vy taky uhýbáte od tématu. Když jsem Vám dokázal, že pro standardní C++ není foreach problém, uhnete od toho a namísto toho mě napadnete za moc, ale celé podstatě tvrzení uhnete. Když Vás upozorním na to, že QString nefunguje v threadech, tak je to v dokumentaci. Když Vás upozorním na to, že QString není ani exception safe, tak už je to vágní obvinění. Ale já to klidně můžu ukázat na zdrojácích Qt, máte-li zájem. Co se týká knihovny C++, tak ta funguje opravdu za jakýchkoli normálních okolností, rozhodně její omezení je tak 10x menší, než omezení obdobných tříd v Qt. Když Vám to dokazuje, tak Vás to pobaví, odpověď nemáte žádnou.

Kde jsou to teda evidentní snadno dokazatelné nepravdy? To, že celou dobu lživě prohlašujete, že moc není preprocessor a doufáte, že Vám to někdo sežere? Nebo nejdřív dokazujete, že ve standardním C++ není možné udělat tak komfotní foreach jako v Qt, a když Vám dokáži, že to není pravda, tak pravda je kde? Když Vám dokazuji, že omezení Qt knihovny jsou řádově větší, než omezení standardní knihovny a jasně vyjmenovávám kde?

Vy se zmůžete hlavně na to, že "jste pobaven", a že "jsou to snadno dokazatelné nepravdy". Dokonce jste se pokusil znevážit i mě jako autora. Upřímně řečeno, mám pocit, že politicky se chováte víc Vy.

[Lubos Lunak]

(Ach jo, preci to asi jen bude chripka. Jeste ze se nemusim nudit.)

> Kde jsou to teda evidentní snadno dokazatelné nepravdy?

• "Moc je preprocesor" (nekolikrat opakovano, napr. 21:51) - viz. ty obrazky trochu vyse (09:44) vcetne definice z wikipedie
• "Co svět světem stojí a od té doby, co existuje norma jazyka C++, tak je tam všechno, co Trolltech řeší svými proprietárními řešeními." (01:31) - v norme jazyka C++ nejsou nikde napr. properties editovatelne z designeru (a ta veta je to tom, ze v norme C++ je vsechno, co TrollTech resi svymi prostredky, ne o tom, jestli to ma smysl nebo neco na ten zpusob)
• "O tom [ze chteli pouzit] Objective C to přímo píšou ve zdůvodnění, proč použili preprocessor." (13:48) - to uz jsme probrali, nic takoveho se tam nepise
• "Vše, co Qt dělá preprocesorem, tak C++ zvládně přímo." (00:48) - na to je jako odpoved nejlepsi zacatek 17:17, kde je tohle tvrzeni odvolano
• "O foreach se s Vámi ohledně nutnosti moc preprocessoru bavit nebudu. Odkážu Vás pouze na makro BOOST_FOREACH, které dělá to samé a stejně jednoduše, co Qt4, akorát nepotřebuje žádný moc preprocessor, vystačí si se standardními prostředky jazyka C++." (17:17) - na to je asi nejlepsi odpoved "Já nevím, jestli foreach potřebuje moc" (21:51), zkusit si foreach pouzit a pritom se moc ani nedotknout nebo se jednoduse na tu definici foreach v qglobal.h podivat a videt, ze je to ciste C++ (ta ne-gcc varianta)
• "Ne, věřte mi, že naprostá většina kompilátorů prostě najednou bere jak příkazy makroprocesoru, tak příkazy C/C++." (16:35) - vzhledem k tomu, ze vysledkem pouziti prikazu makroprocesoru mohou byt i prikazy C/C++, je naprosto evidentni, ze se to nemuze delat naraz, ale nejdriv makroprocesor, az potom C/C++; ze se to navenek tak nejevi jeste neznamena, ze to tak porad interne neni
• "kdy Qt knihovna opraví chybné zamykání objektů v mnoha třídách" (13:48) - v dokumentaci je popsane, jak je na tom ktera trida s thready a je to tak podle designu; QString je reentrantni a je to spravne implementovane, to, ze by to nekdo rad videl jinak jeste neznamena, ze je to chybne
• "Zároveň for_each v STL funguje o poznání jednodušeji, pokud se začneme bavit o kontejnerech v STL." (17:17) - foreach v Qt je jen hezci zapis pro funkcionalitu std::for_each( container.begin(), container.end(), [kod] )
• "Vy taky uhýbáte od tématu. Když jsem Vám dokázal, že pro standardní C++ není foreach problém, uhnete od toho a namísto toho mě napadnete za moc, ale celé podstatě tvrzení uhnete." (21:51) - az na to, ze diskuze byla nejdriv o for_each ze STL (13:18,13:48,15:34) a pak najednou, kdyz v 15:34 byl docela dobry priklad toho, jak for_each z STL muze byt horsi nez foreach z Qt, nekdo (17:17) najednou uhnul k michani std::for_each a foreach makra a tomu, ze foreach jde udelat i s normalnim C++ (coz, nakonec, je pravda, protoze foreach z Qt je udelane s normalnim C++)
• "To, že celou dobu lživě prohlašujete, že moc není preprocessor a doufáte, že Vám to někdo sežere?" (21:51) - viz. prvni polozka seznamu

Rad bych Vas pozadal, az zase nekde bude neco o Qt, abyste se zdrzel jakychkoliv pripominek, protoze Qt vubec nerozumite a mate o Qt dost pomylene predstavy. Kdyz se Vam nelibi, nikdo Vas Qt pouzivat nenuti, ale Vy nenutte svoje bludy dalsim. Diky.

[Miloslav Ponkrác]

Já už nemám sílu ani čas, takže jenom stručně:

Moc je preprocessor. Od té doby, co vidím v návodu na Qt, jak se v cpp souboru objeví #include "neco.moc". Od té doby je to pro mě preprocessor. Možná mám ale jenom blbý návod...

V normě jazyka nejsou properties, protože se to dá udělat i bey zavádění speciální featury do C++.

To, že se tu hádáte o tom, jak to dělá kompilátor interně je naprosto irelevantní. Jak jsem napsal, v tom případě má každý kompilátor minimálně 10 preprocessingů.

QString není reentrantní a nic na tom nemění ani to, že to Trolltech, nebo kdosi tvrdí. Zde zdroják mluví až moc jasně.

Co se týká for_each, Vaše ukázka je jen o tom, že jste prostě použil for_each na jakýsi objekt z Qt, což je pro mě nezajímavé. Mě zajímá, co je efektivní při použití standardních kontejnerů STL. A jak říkám, makro BOOST_FOREACH řeší i krásný a přehledný zápis.

Znovu říkám, pokud ukázka použití moc na stránkách Trolltechu je pravdivá, pak moc je normální preprocessor.

Až se bude mluvit o Qt, můžete si být jistý, že mlčet nebudu. Snad Vám to udělá radost. Qt sice dokonale neznám, což přiznávám, protože po krátkodobém používání jsem uznal, že je to prasárna s nepřijatelnou licencí.

[Lubos Lunak]

> Moc je preprocessor. Od té doby, co vidím v návodu na Qt, jak se v cpp souboru objeví #include "neco.moc". Od té doby je to pro mě preprocessor. Možná mám ale jenom blbý návod...

Aha. Myslim, ze tohle mluvi za vse. Takze, dle stejne logiky, kalkulacka je vlastne SQL interpretr, protoze vysledek vypocitany na kalkulacce jde pomoci SQL pridat do databaze.

V drive zminovaneho prispevku z 9:44 je jasne vysvetleno, ze moc neni preprocesor a proc se nekdy dela #include "a.moc". Takze si muzete vybrat

• snazite se tu debatovat o necem, cemu vlastne vubec nerozumite
• snazite se tu debatovat o necem, co jste si vlastne ani neprecetl
• snazite se tu hadat za kazdou cenu

Vzhledem k te vyse citovane casti, kde si pletete moc s C/C++ preprocesorem, bych to hadal na prvni moznost, ale ani ty ostatni nemuzu vyloucit.

A mimochodem, ja jsem core vyvojar KDE a krom jinych veci jsem treba i trochu ovlivnil kod, ktery generuje moc z Qt3. Nepotrebuju vysvetlovat, co je moc nebo jak to funguje, ja to vim. Nebudete snad jeste mit tu drzost tvrdit, ze Vy tomu rozumite vic, protoze jste si to na chvili i zkusil a ja to jen nekolik let (nejen) pouzivam?

[#Tom]

Ne nadarmo někteří říkají, že latina patří k dobrému vzdělání. Hodí se třeba k pochopení některých cizích slov, jako je například slovo preprocesor.

[#Tom]

Tady je for_each hned na dva způsoby a ještě jednou totéž přímo přes itetátory:

#include <iostream>
#include <vector>
#include <cmath>

using namespace std;

template<typename T> void pohrajeme_si_s_vektorem_poprve(vector<T>& v) {
  for (typename vector<T>::iterator vi = v.begin(); vi != v.end(); vi++) {
    cout << "poprvé  - " << *vi << endl;
  }
}

template<typename T> void vypis(T& t) {
  cout << "podruhé - " << t << endl;
}
template<typename T> void pohrajeme_si_s_vektorem_podruhe(vector<T>& v) {
  for_each(v.begin(), v.end(), vypis<T>);
}

template<typename T> class Cvypis {
    public: void operator()(T& t) { cout << "potřetí - " << t << endl; }
};
template<typename T> void pohrajeme_si_s_vektorem_potreti(vector<T>& v) {

  for_each(v.begin(), v.end(), Cvypis<T>());
}

int main() {
  vector<double> hodnoty;
  hodnoty.push_back(3);
  hodnoty.push_back(M_PI);
  hodnoty.push_back(exp(-1));
  cout << "První cyklus..." << endl;
  pohrajeme_si_s_vektorem_poprve(hodnoty);
  cout << "Druhý cyklus..." << endl;
  pohrajeme_si_s_vektorem_podruhe(hodnoty);
  cout << "Třetí cyklus..." << endl;
  pohrajeme_si_s_vektorem_potreti(hodnoty);
  return 0;
}

[Sinuhet]

Bezdecne jste tu nadherne ilustroval, proc pouzivat bud standardni std::for_each, nebo lepe BOOST_FOREACH.

template<typename T> void pohrajeme_si_s_vektorem_poprve(vector<T>& v) {
  for (typename vector<T>::iterator vi = v.begin(); vi != v.end(); vi++) {
    cout << "poprvé  - " << *vi << endl;
  }
}

Ma byt ++vi. (A to sou lidi schopni napsat daleko vetsi zverstva, jako vi < v.end())

[#Tom]

A není to jedno? Možná bude déle trvat překlad, ale výsledný kód bude po všech optimalizacích stejný. Uschovaný iterátor před posunem se k ničemu nevyužije, takže je vypuštěno i ono uschování. Porovnávání iterátorů mi přijde poněkud zvláštní, ani jsem nevěděl, že to jde.

[Sinuhet]

Jestli bude kod odoptimalizovan, to zalezi na velmi mnoha faktorech. Kazdopadne je takovy zapis zcela zbytecny a potencialne prinasi jedine problemy.

[Jáchym Čepický]

shodou okolností nedávno v jednom mailinglistu proběhla diskuze, vyšumějící do ztracena, v čem vyvíjet nové GUI. Jak je na tom GTKMM na Macích?

[paskma]

GTKMM je jen tenký obal na vysoké úrovni abstrakce a je tedy dobře přenostilelné. Otázka tedy stojí jak je to s GTK samotným. Detaily neznám, ale kdysi jsem viděl screenshoty Gimpu pod Masoxem, ale bylo to ve vývoji. Tedy myslím.

[Daniel Kvasnička ml.]

no to je krasa tady to je flejm jak ma bejt

pratele, me by zajimalo jedno. pojem kvalita GUI toolkitu...co si pod nim predstavujete?

Mam pocit, ze mnoho z vas pomeruje tu kvalitu podle toho, jak silny orgasmus dostanete z jeho API.

Je GTK nativni na ruznych OS? Neni. Uzivatele OS X by vas vsechny meli radi! Ani ve Windows to nevypada nativne, i kdyz pokusy tu jsou.

Jak je GTK rychle a pametove narocne v porovnani treba s tim Qt?....

Jak kvalitni WYSIWYG nastroje pro tvorbu GUI jsou pro GTK v porovnani treba s Qt Designerem?...

Nerikam, ze GTK je nepouzitelne. Je tu ta vec s licenci, nekteri zakaznici treba na vzhled a pamet kaslou (?) etc... Jen mam pocit, ze ste se tu vsichni utopili ve filozoficko-technickych zvastech a vubec vas nezjima, jaka bude vysledna aplikace.

[paskma]

Já jsem uživatel GNOME a GTK GUI se mi moc líbí. A beru to tak, že přenést na wokna to půjde a bude to pořád vypadat dost slušně.