Portál AbcLinuxu, 26. dubna 2024 05:55
Nové programy, které byly zařazeny do oficiální distribuce GNOME 2.24: Hamster, aplet pro sledování pracovního času (+ krátký rozhovor s vývojářem Hamsteru); Empathy, univerzální komunikátor (Jabber, ICQ apod.); Ekiga, softwarový telefon s podporou SIP a H.323.
V minulém dílu seriálu o novinkách v GNOME 2.24 byly obsaženy informace o aplikacích, které mají v projektu GNOME své místo již delší dobu. Nyní se můžeme mrknout na projekty, pro něž je GNOME 2.24 první štací…
V předchozím vydání GNOME se uživatelé mohli radovat hned z několika nových aplikací. Jednalo se o Vinagre, prohlížeč vzdáleného pracovního prostředí, Cheese, aplikaci pro práci s webovou kamerou, a Anjutu, vývojové prostředí. Anjuta byla však spíše zánovní než nová.
GNOME 2.24 je na tom nejinak a dočkalo se také tří nových aplikací. Jsou jimi: aplikace pro analyzování času Hamster, komunikátor Empathy a aplikace pro audio a videohovory Ekiga. Podobně jako Anjuta, ani Ekiga není nová, nýbrž zánovní.
V tomto článku budou všechny tyto aplikace postupně probírány.
První z aplikací, jež si dnes představíme, je Hamster. Hamster je anglický výraz pro křečka, a možná proto je cílem této aplikace umožnit, aby si uživatel mohl nakřečkovat svůj čas a použít jej ve vhodnější chvíli. O tom ale dále.
Co Hamster nabízí? Jednoduše řečeno pomáhá měřit a analyzovat čas. Nejedná se však o žádnou pomůcku pro laboranty nebo sportovní trenéry, jak by se na první pohled možná mohlo zdát. Jedná se o nástroj, s jehož pomocí uživatel odhalí, jaké činnosti věnuje během dne nejvíce času, a na základě tohoto měření může proškrtat svůj diář.
Použití Hamsteru připomíná „píchačky“. Píchačky byly zařízením, které se především dříve používalo pro evidenci přítomnosti zaměstnanců na pracovišti. Když zaměstnanec ráno přišel do podniku, u vrátnice si „píchnul“ příchod. Když z podniku odcházel, píchnul si odchod. Rozdíl mezi odchodem a příchodem byla doba, kterou v podniku zaměstnanec strávil. Alespoň teoreticky.
Hamster tohoto přístupu využívá také. Když uživatel začne dělat nějakou činnost, dá aplikaci vědět. Pokud ji přestane dělat, píchne si odchod.
Po nějaké době má uživatel přehled o tom, co dělal a jakou dobu tomu věnoval. Každá činnost má svůj název a může být zařazena do kategorie (skupiny činností). Činnosti i kategorie jsou plně v režii uživatele a je také jen na něm, podle jakého kritéria bude činnosti třídit.
Z tohoto popisu je jasné, že se Hamster hodí především do firem. U „domácích“ uživatelů, kteří tráví celý svůj čas prohlížením webových stránek o kočkách nebo kolotočích, nejspíš nemá smysl Hamster používat. Naopak zaměstnancům může být velmi dobrým pomocníkem. Pokud zaměstnanec například zjistí, že devadesát procent času tráví na poradách, asi je čas zefektivnit využití času…
Nicméně – fantazii se meze nekladou a je na každém, jak Hamster využije.
Více než klasickou aplikací je Hamster appletem. Jeho místo je totiž na panelu, ze kterého se spouští i ovládá. Na panelu je vždy vidět název činnosti, kterou uživatel provádí, a také doba, po kterou se jí věnuje. Kliknutím na applet je možno změnit činnost nebo pozastavit celé měření. Nejdůležitější funkce jsou tedy velmi rychle dostupné.
Aktivity i dobu práce na nich je možné přidávat i zpětně, což je potřeba především tehdy, je-li někdo buď zapomnětlivý, nebo „podvodník“. Za tyto případy ale autoři aplikace rozhodně neručí…
Výsledkem používání aplikace Hamster je přehled činností – soupis všech činností vykonávaných za určitý časový úsek. Přehled činností je zobrazen v samostatném okně, a to jako seznam a také pomocí grafu. Přehled si lze nechat zobrazit jako denní, týdenní nebo měsíční souhrn.
Z každého souhrnu je možné se dozvědět, kolik času uživatel věnoval všem činnostem dohromady, jaké je rozložení věnovaného času mezi kategorie a také, jaký časový příděl dostala každá činnost.
Přehled lze navíc exportovat jako webovou stránku.
Jelikož je aplikace Hamster poněkud neobvyklá, položil jsem několik otázek jejímu vývojáři Tomsu Baugisovi, aby objasnil (a obhájil) její účel. Výsledkem je následující krátký rozhovor.
Hmm, celá tahle otázka ohledně času je zajímavá.
Co se mě týká, já začal vytvářet Hamster proto, abych zjistil, čím nejvíc trávím čas. Teď je pro mě Hamster pomocníkem číslo jedna kvůli tomu, že mě popohání k práci. Používám ho proto, abych se dostal do určitého rytmu – když do něj napíšu, že „teď budu dělat nějakou práci“, mám to napsáno přímo přede mnou a tu práci prostě dělám.
Jinak jsem ale skeptický k aplikacím pro „šetření času“. Zkrátka – když máš nepořádek ve svém životě, nehledej žádné nástroje k šetření času, ale prvně se zbav toho nepořádku a až pak se sháněj po nějakých aplikacích…
Abych ale nezapomněl! Hamster je „měřič času“ (anglicky time tracker), z čehož plyne, že čas měří, ale nijak se jej nesnaží organizovat nebo šetřit. To je jen na tobě.
Nicméně ano – Hamster může vylepšit tvou produktivitu, pokud přesně víš, co od něj chceš. Když jej začneš používat, bude ti sice nějakou dobu trvat, než si zvykneš na „porcování“ času a než najdeš takové časové úseky, které ti budou vyhovovat, ale když to zvládneš, Hamster ti skutečně může pomoci.
Jo, věř mi.
Rád si v něm prohlížím uplynulý čas, hezky týden po týdnu, a líbí se mi, jak při tom ty sloupečky tancují (sloupce grafů jsou animované; při načtení jakoby „vyrostou“ – pozn. aut.)…
A zjistil jsem, že jsem nejproduktivnější ve středu v podvečer. Pořád nevím proč, ale je to tak. No, a právě tenhle čas věnuji na vývoj Hamsteru.
Hamster není zcela typickou aplikací. Zaměřuje se na poměrně úzkou skupinu uživatelů a ne všichni jej využijí. Nicméně těm, kterým je určen, může odvést skvělou službu při snaze lépe organizovat vlastní čas.
Takže pěstujme křečky – Země je kulatá a místa je tu dost.
Do této chvíle nabízelo pracovní prostředí GNOME ke každé běžné uživatelské činnosti alespoň jednu příslušnou aplikaci. S jednou výjimkou: chyběla aplikace, která by umožňovala využívat komunikační sítě, jako je například Jabber. Přestože si uživatelé našli schopné náhrady tohoto nedostatku, nikdy se nejednalo o plnohodnotné zástupce.
Situaci se nyní snaží zvrátit projekt jménem Empathy, tedy nový oficiální komunikátor prostředí GNOME. Na následujících řádcích probereme jeho technickou stránku a také se podíváme na jeho vlastnosti z pohledu uživatele.
Na Empathy je nejzajímavější jeho technické řešení, poněvadž má většinu charakteristik, na které se (zejména) poslední dobou kladou nároky: je totiž modulární, znovupoužitelné a jeho části spolu komunikují při zachování dostatečné abstrakce rozhraní.
Nejprve je třeba říci, ze kterých částí se Empathy skládá, protože se nejedná o jednolitý kus programu. Hlavní části Empathy jsou dvě:
Právě použití Telepathy dělá Empathy tak zajímavé.
Telepathy je projekt (realizovaný pod křídly organizace FreeDesktop.org), který se snaží nabídnout technologii, jež by umožnila jednotně přistupovat k nejrůznějším komunikačním sítím. Jednoduše řečeno se jedná o technologii, kterou mohou sdílet všechny aplikace toužící po využívání komunikačních sítí.
Projekt, jako je Telepathy, tu dosud chyběl, a tak si každá aplikace řešila přístup ke komunikačním sítím po svém. Některá s větším úspěchem, jiná s… ne tak velkým úspěchem.
Na Telepathy je krásné, že má všechny charakteristiky zmíněné výše: modularitu, znovupoužitelnost a abstrakci rozhraní vrstev. Telepathy je zcela nezávislé na grafickém rozhraní a funkce pro obsluhu jednotlivých sítí jsou do něj přidávány prostřednictvím modulů.
Telepathy je svým způsobem podobné technologii GStreamer: aplikacím stačí implementovat GStreamer, aby mohly pracovat s libovolnými multimédii. O víc se aplikace už nestarají, neboť jejich schopnosti (co se týče práce s multimédiálním obsahem – ať už se jedná o vstupy, výstupy nebo formáty souborů) pak už závisí jen na tom, jaké moduly pro GStreamer si uživatel nainstaluje. U Telepathy je situace zcela analogická.
V současné době dostupné moduly, které se starají o jednotlivé komunikační sítě, jsou vypsány na následujících řádcích (všechny mají vlastní jména):
Dva z modulů se spoléhají na produkty třetích stran. Prvním je modul Haze využívající technologii Purple, což je software, který vznikl v rámci komunikátoru Pidgin. Jedná se vlastně o programátorskou knihovnu, která poskytuje přístup k různým komunikačním sítím (dělá de facto to samé jako Telepathy, jen ne tak obecně). Sítí, se kterými umí Purple pracovat, je přes patnáct.
Druhým modulem spoléhajícím se na třetí stranu je Telepathy-SofiaSIP. Ten využívá technologii SofiaSIP, za kterou stojí finská společnost Nokia. Jak už název napovídá, zprostředkovává přístup k síti SIP.
Zajímavostí je, že SofiaSIP není jediným produktem od Nokie, který se dostal do Telepathy. Dalším želízkem v ohni je Mission Control – komponenta Telepathy starající se o správu připojování k účtům komunikačních sítí. Mission Control i SofiaSIP jsou svobodný software.
Nyní se od Telepathy přesuneme k Empathy.
Funkce dostupné v aplikaci Empathy jsou rozděleny do dvou knihoven: libempathy a libempathy-gtk. První jmenovaná knihovna má na starosti funkce nezávislé na uživatelském rozhraní; druhá jmenovaná naopak nabízí prvky uživatelského rozhraní.
Uživatelské rozhraní Empathy je založeno na aplikaci Gossip, což byla aplikace (v současné době se již nevyvíjí), která umožňovala komunikaci po síti Jabber.
Rozdíl mezi Empathy a Gossip není na první pohled příliš patrný; kardinální rozdíly jsou totiž skryty pod povrchem. Většina jich je jmenována v odstavcích výše, a tak je jenom shrneme: použití Telepathy namísto vlastního řešení, rozdělení kódu do dvou knihoven a přepsání části kódu.
Model uživatelského rozhraní Empathy jde obvyklou cestou aplikací tohoto typu: skládá se ze dvou hlavních oken, jimiž jsou seznam kontaktů a okno s konverzacemi, přičemž okno s konverzacemi samozřejmě podporuje karty. Jedná se o vžitý a dobrý návrh uživatelského rozhraní a není důvod na něm něco měnit.
Nepostradatelnou vlastností je taktéž podpora ikonky v oznamovací oblasti na panelu. Díky ní je možné spouštět jistou množinu funkcí Empathy a také indikuje uživatelův stav (jestli je k sítím připojen, odpojen atd.).
Seznam kontaktů je možné zobrazit buď v klasickém, nebo „kompaktním“ zobrazení, ve kterém je značně zredukována potřeba místa na obrazovce. Kontakty si lze samozřejmě zařazovat do skupin, přičemž jeden kontakt může být i ve více skupinách. Dobrý dojem budí také velmi pěkně zpracovaná historie konverzací, kterou je možné procházet pomocí kalendáře, případně je v ní možné vyhledávat.
Empathy je dobře integrováno do prostředí GNOME, což zahrnuje například reakce na změny stavu šetřiče obrazovky, reakce na změny stavu připojení k síti nebo využívání systémové klíčenky.
Velkou výhodou Empathy je, že se nesoustředí na jedinou komunikační síť, ale umí pracovat s velkým množstvím sítí. Jmenujme například Jabber (včetně přenosu zvuku a obrazu), ICQ, MSN, IRC nebo SIP. Empathy tak umožňuje komunikovat textem, hlasem i obrazem a uživatel tudíž nepotřebuje pro každou síť zvláštní aplikaci. Toho je docíleno díky použití technologie Telepathy, jak již bylo zmíněno v minulém oddílu.
Je však důležité zmínit, že Empathy v současné době neimplementovalo všechny funkce dostupné z Telepathy. Například ještě neexistuje podpora pro přenos souborů – na tuto funkci, ale i některé další, je třeba si počkat do dalších vydání.
Empathy je za posledních několik vydání možná nejzásadnější aplikací, která se dostala do GNOME. Její přínos spočívá také v tom, že přináší technologii Telepathy do GNOME jakožto celku. Nyní může kterákoli aplikace využívat knihovnu libempathy-gtk a obohatit se tak o možnost použití komunikačních sítí.
Empathy také potvrzuje nástup dobře navržených, na implementaci nezávislých řešení, jako jsou například PolicyKit, PackageKit nebo právě Telepathy.
Nicméně je také dobré dodat, že Empathy je teprve na počátku své cesty a potřebuje čas, aby se stalo skutečným žralokem v hlubokých vodách softwaru. Avšak i navzdory tomu, že se jedná o první verzi, nabídlo Empathy oslňující množství funkcí a rozhodně se nemá za co stydět. Považujme jej tedy za žraločí mládě.
Jak již bylo předesláno v úvodu článku, Ekiga není úplně novou aplikací. Počátky tohoto projektu se totiž datují o několik let zpět, konkrétně do roku 2004. Ekiga je aplikace, která sice vždy využívala technologie nabízené vývojovou platformou GNOME (však byl také její původní název GnomeMeeting), nicméně nebyla oficiální projekt GNOME. A právě to se změnilo s vydáním třetí řady.
Vzhledem k tomu, že je Ekiga na našich pevných discích již několik let a že se jedná o velmi známou aplikaci, nebudu ji představovat tak zevrubně jako Hamster a Empathy, ale jen velmi stručně a spíše heslovitě.
Stručný popis aplikace Ekiga zní: softwarový telefon. Pomocí Ekigy je tedy možné uskutečňovat audio a videohovory přes Internet, a to pomocí protokolů SIP a H.323. Ekiga je kompatibilní s jinými podobně zaměřenými produkty, které také využívají tyto protokoly, a není tedy třeba se bát o interoperabilitu.
Ekiga umí pracovat s velkým množstvím kodeků pro audio i video a podporuje také akcelerované video.
Do GNOME je Ekiga integrována například tím, že využívá adresář aplikace Evolution.
Je samozřejmě otázka, jestli si Ekiga nebude (alespoň částečně) konkurovat s Empathy, jelikož i Empathy umí pracovat s protokolem SIP. Odpověď zní možná ano.
Je však třeba chápat, že záběr Ekigy je (minimálně v současné době) mnohem širší než záběr Empathy. Ekiga totiž pronikla na mnoho operačních systémů; mimo těch unixových například na Microsoft Windows. Této schopnosti je dosaženo tím, že se Ekiga umí na systémech, kde není GNOME dostupné, vzdát jeho podpory a pracovat bez něj.
Další rozdíl mezi oběma aplikacemi je v různých úrovních splynutí s projektem GNOME. Obě aplikace sice využívají vývojovou platformu GNOME, ale pouze Empathy respektuje jeho vývojový cyklus – Ekiga má svůj vlastní, na GNOME nezávislý.
zdroj: http://blog.ekiga.net/
Sami vývojáři si představují, že by se Ekiga s Empathy měla spíše doplňovat – minimálně to vyplývá z oficiálních poznámek k vydání GNOME 2.24.
Co se týče novinek ve třetí řadě aplikace, Ekiga zcela přepracovala uživatelské rozhraní, má vylepšenou podporu komunikačních protokolů, lépe pracuje s různými kodeky a přináší mnoho dalších nových vlastností a funkcí.
GNOME 2.24 nabízí tři nové aplikace a dokázalo tak zopakovat šíři nabídky nových aplikací, které se podařilo dosáhnout minulému vydání. Vzhledem k relativně krátkému (půlročnímu) vývojovému cyklu GNOME to je úspěch.
Verze 2.24 je také důkazem, že v GNOME mají své místo jak aplikace určené nejširší uživatelské obci (Empathy), tak i aplikace určené relativně úzkému kruhu uživatelů (Hamster).
Bez zajímavosti není ani pohled na programovací jazyky, které nové aplikace používají. Empathy je napsáno v jazyce C (stejně jako Vinagre a Cheese), Hamster používá Python. Nezdá se tedy, že by se v GNOME dostávalo většího prostoru jazyku C# (a technologii Mono obecně), jak by to mohlo vypadat z různých komentářů.
Závěrem je třeba připomenout, že všechny nové aplikace jsou teprve na startu své kariéry. K tomu, aby jejich vývoj neustával a třeba i naopak zrychloval, potřebují podněty od uživatelů. Říct svůj názor může každý. Nic to nestojí, ale zato to hodně přináší.
To co jste napsal je obyčejný FUD a plyne jedině z neznalosti.
Pokud chcete psát něco o C++, měl by jste si první prostudovat možnosti tohoto jazyka a ne šířít nesmysly typu, že C++ je vždycky pomalejší než C. Právě naopak, v C++ máte možnosti vytvořit vysoce optimalizované funkce, které by jste v C vytvořil asi tak pomocí miliónů maker a 20 hlavičkových souborů, které by jste pomocí nastavených maker includoval třeba 20x po sobě. Samozřejmě, že jsem to trošku nafoukl, jediné co k tomu můžu napsat je, že váš kód by na první pohled nikdo nepochopil ;)
Pokud vypnete v C++ vyjimky a RTTI, máte totálně ekvivalentní jazyk, co se týče generování kódu a rychlosti jako C, a navíc máte neuvěřitelné možnosti při psaní kódu, jaké v C mít nikdy nebudete.
Pokud vám vadí demanglování jmen funkcí, můžete použít extern "C".
Překladač už při překladu ví, jaký index má použít, navíc může díky znalosti virtuálních funkcí cachovat jejich počáteční adresu.
MSVC navíc používá speciální konvenci, kdy se jako parametr this používá registr ecx, může se to zdát jako banalita, ale toto je úplně perfektní věc pro vytváření delegátů. To už jsme ale trochu odbočili :)
29.10.2008 01:33
29.10.2008 10:22
struct ObjectVTable
{
void (*vfunkce)(Object* self);
};
struct Object
{
ObjectVTable* vtable;
};
při volání virtuální funkce se provede úplně jednoduchá věc:
Object* o = ... o->vtable->vfunkce(o);Pokud překladač ví, že se jedná o tabulku virtuálních funkcí (což v případě C++ implementace ví), tak si hodnotu vtable může uchovat v registru a vygenerovat lepší kód než v C implementaci. Index vfunkce() je v našem případě 0. Je to věc známá při překladu o žádné prohledávání tabulky se nejedná.
29.10.2008 21:37
Stanislav Brabec | skóre: 45
| Praha
this. To se však často nestává, a navíc i tato výhoda je dána pouze kvalitou optimalizátoru.
Jak už bylo výše řečeno, toto platí za předpokladu, že nepoužijete RTTI a k volbě instance použijete přetížení. Pokud kód větvíte podle toho, zda je argument int nebo float, je to něco jiného.
Tedy přesně totéž, co udělá programátor v C nebo v assembleru, pokud potřebuje proměnný odkaz na funkciÁno, toto jsou virtuální funkce. Ale já bych dodal ještě to, že v C++ překladač ví, že se jedná o vtable a ta by se neměla změnit při volání její funkce, takže optimizér si klidně může uložit vtable do registru a při volání více funkcí se ta dereference udělá jen 1x.
Jediná teoretické výhoda C spočívá ve virtuální funkci samotné, pokud by nebylo potřeba předávat implicitní this. To se však často nestává, a navíc i tato výhoda je dána pouze kvalitou optimalizátoru.Pokud se toto stane, můžeme si přeci i v C++ udělat strukturu funkcí a tu používat pro tento účel - toto se používá v grafických knihovnách.
Pokud kód větvíte podle toho, zda je argument int nebo float, je to něco jinéhoTady se neshodnem. Je to stejné. Pořadí přetížených funkcí v tabulce virtuálních funkcí má taky logiku, takže se jedná opět o věc známou z překladu.
29.10.2008 22:10
Stanislav Brabec | skóre: 45
| Praha
Ale já bych dodal ještě to, že v C++ překladač ví, že se jedná o vtable a ta by se neměla změnit při volání její funkce, takže optimizér si klidně může uložit vtable do registru a při volání více funkcí se ta dereference udělá jen 1x.K tomu lze v moderním C použít
-fstrict-aliasing.
Měl jsem na mysli větvení v kódu, tedy RTTI, k němuž je třeba předávat identifikátory typu jako skryté proměnné.Pokud kód větvíte podle toho, zda je argument int nebo float, je to něco jinéhoTady se neshodnem. Je to stejné. Pořadí přetížených funkcí v tabulce virtuálních funkcí má taky logiku, takže se jedná opět o věc známou z překladu.
Zná index, nezná hodnotu na tomto indexu uloženou.Jo presne tak.
Jediná teoretické výhoda C spočívá ve virtuální funkci samotné, pokud by nebylo potřeba předávat implicitní this. To se však často nestává, a navíc i tato výhoda je dána pouze kvalitou optimalizátoru.Intel i MSVC garantuji, ze this bude vzdy ulozen v registru, nicmene GCC ho (pokud neni potreba) vubec nepreda. Intel by zase mel umet provadet devirtualizaci (mozna uz i GCC, nevim, uz je to docela dlouho co jsem zkoumal jake optimalizace umi), diky cemu je pak mozne virtualni funkce, ktere nejsou zakryte pouzivat s casnou vazbou a diky tomu i inlinovat.
Jak už bylo výše řečeno, toto platí za předpokladu, že nepoužijete RTTI a k volbě instance použijete přetížení. Pokud kód větvíte podle toho, zda je argument int nebo float, je to něco jiného.Smysl tehle vety mi dost unika. Mam pocit ze pletete dohromady zakryti metody pri dedicnosti a pretezovani metod/funkci.
30.10.2008 10:02
Stanislav Brabec | skóre: 45
| Praha
To, že zatímco přetěžování lze plně vyhodnotit během kompilace, konstrukce typuJak už bylo výše řečeno, toto platí za předpokladu, že nepoužijete RTTI a k volbě instance použijete přetížení. Pokud kód větvíte podle toho, zda je argument int nebo float, je to něco jiného.Smysl tehle vety mi dost unika. Mam pocit ze pletete dohromady zakryti metody pri dedicnosti a pretezovani metod/funkci.
if (typeid(argument1) == int) mají režii i v době běhu programu.
cudna logika - kedze C nema objektove rozsirenia je asi logicke ze vysledna struktura programu bude inaPokud v C naprogramuju to, co C++ udělá za mě, tak bude struktura programu úplně stejná. Pokud C++ překladač navíc uplatní nativní možnosti C++, bude výsledná binárka lepší ta z C++.
ci aj v asemblere budete brutalne OBJEKTOVYJá dokážu zvážit to, na co použiju asm a na co ne. Pokud chcete být objektový v asm, klidně můžete, ale budete psát podobné věci, jaké vám lezou z překladu C++.
v linuxe sa nepouziva c++ jednoducho preto ze jeho rezia je vacsia ako v CVídím, že existuje opravdu hodně lidí, co takovému nesmyslu věří. Otázka je, co berete jako C++. Jestli jazyk, nebo STL, nebo rozšíření o výjimky a RTTI. Já beru C++ jako jazyk a STL jako knihovnu, kterou nemusím použít. Je jasné, že pokud to s STL přeženu, tak bude program větší, ale nikdy nebude pomalejší. Pokud chci malé binárky, tak jednoduše nepoužiju STL ale hlavně výjimky. Pokud tedy tvrdíte, že C++ je pomalejší než C, tak řekněce, co konkrétně ? Podle vaší reakce mám totiž pocit, že o C++ nevíte skoro nic.
btw na vyslednu rychlost to ci sa nieco inkluduje raz alebo 100x nema vplyv ci mate inu skusenostToto není debata o překladu z C/C++ do asm.
PRECO by mal niekto programovat v C rovnako ako v C++??? uvedomte si ze C++ a C su dva rozdielne jazykyProc by mel nekdo pouzit druhy jazyk? Jenom proto ze to rikate? Samozrejme ze to jsou rozdilene jazyky, nicmene C++ je vybudovano nad Ceckem a oba standardy se snazi drzet maximalni moznou vzajemnou kompatibilitu.
"Pokud chci malé binárky, tak jednoduše nepoužiju STL ale hlavně výjimky" - co viac povedat - vieto o com pisete? mam pocit ze ste si len cosi precital na webe, tomu co tam pisali ste neporozumel a teraz z toho gulasu co mate v hlave tu hlasate podobne veci.Zakladni problem C++ pri kompilaci je, ze do binarnich souboru cpe obrovske mnozstvi symbolu. Po stripnuti techto symbolu jsou obvykle datove objemy binarek v jazycich C a C++ velmi podobne. Btw. kdo dnes proboha optimalizuje na velikost binarky? To se dela jedine u embeded zarizeni, kam bych C++ v dnesni dobe nedoporucil (nedostatek kvalitnich kompilatoru).
inac pre vase info pouzivam C++ od doby co vysiel vobec prvy prekladac Borlandu pre toto prostredie.Tak si obcas zkuste zjistit co vam ten kompilator s kodem dela.
Uvedomte si ze ludia co robia na kerneli a su postaveny v hierarchii vyssie urcite nemaju ziadny problem so zvladnutim C++,Java,...,...Coz nema vubec nic spolecneho s tim ze na jadre delaji tisice lidi a spousta z nich C++ neumi.
Clovek co vie programovat sa v novom jazyku behom mesiaca, dvoch orientuje absolutne pohodlne.Zacinam docela chapat proc tady placate takove kraviny.
"Pokud chci malé binárky, tak jednoduše nepoužiju STL ale hlavně výjimky" - co viac povedat - vieto o com pisete?Vím. Pokud by jste o C++ opravdu něco věděl (což jste mi ukázal pravý opak), věděl by jste, že výjimky vám způsobí nárust binární velikosti kódu asi o 10%. Toto je jediná věc na C++, která vám opravdu zvětší binárky, proto ji hodně projektů nepoužívá (Qt, Kde, aplikace od Google, wxWidgets, ...). PS: Já znám překladač od Borlandu, doma mám dokonce orig. verzi 3.1, kde jsem za dávných dob používál TurboVision.
akych objektov v CMěl by jste se někdy podívat do zdrojových kódu projektů, které jsou napsané v C. Mám totiž pocit, že C programátoři jsou mnohdy více objektově založení než C++ programátoři.
C++ je asi tak 7x pomalsieJenže to nebyl identický kód. Od začátku se tu vede flame o tom, že v C++ je pomalejší stejný kód jako v C, což se vám tady pár lidí snaží vyvrátit, ale marně.
chcete povedat ze vytvorenie objektu v C++ je casovo obdobne narocne ako alokacia pamate v C pre dany typ
class A
{
int x;
int y;
public:
A() { kod1; }
~A() { kod2; }
};
int main()
{ A a; }
Je zcela ekvivalentni (dokonce jde o implementaci, ktera se pouziva pri kompilaci C++ kodu) s:
struct A
{
int x;
int y;
};
void Init(struct A const * a) { kod1; }
void DeInit(struct A const * a) { kod2; }
int main()
{ struct A a; Init(&a); DeInit(&a); }
Ukazte mi ten vas overhead objektu.
.
OK mam dost dlouhou zkusenost z obojiho, mam prekladac, ktery by mel byt optimalizovany (dle vyrobce jak pro C tak pro C++), Metrowerks CodeWarrior. Pokud pouziju C++ tak mi stoupne pametova naroznost o polovinu a beh SW se viditelne zpomali, vzhledem k tomu, ze chvilemi je pro me nutna okamzita reakce, je kobinace C a Asembleru idealni. Nebudu tam cpat C++ ktere jenom ze tam je spolkne nejaky 3,5 kByte Flash z 128kByte a skoro 2kByte RAM z 8k. Navic kazda funkce je vice narocna , protoze sice kon je mensi, ale prilinkovane knihovny vetsi.
A to programuju malo objemove ridici jednotky, kde pro me neni cena tim nedulezitejsim, tedy se mohu rozhodnout, co pouziji.
29.10.2008 07:45
zoul | skóre: 43
| blog: ☂
| Boskovice
29.10.2008 07:55
zoul | skóre: 43
| blog: ☂
| Boskovice
Skoro mi to prijde, ze mas na mysli nejaky jiny jazyk, v cemz me utvrzuje i to, ze v tom shootoutu Objective-C je.
Tomas
30.10.2008 11:15
zoul | skóre: 43
| blog: ☂
| Boskovice
Na desktopove aplikace staci, ale to je vsechno v uvozovkach.Píšou se v něm i hry pro iPhone, bez jakýchkoliv výkonnostních problémů ze strany jazyka. Ono je sice hezký říct, že zasílání zpráv je ve srovnání s voláním funkcí brutálně pomalé, ale doby, kdy pár instrukčních cyklů znamenalo rozdíl mezi pomalým a rychlým programem, jsou dávno pryč. Dneska jsou podobné rozdíly podstatné jen u několika málo procent programů.
29.10.2008 14:22
Algi | skóre: 1
| blog: Sinner
29.10.2008 13:25
Stanislav Brabec | skóre: 45
| Praha
struct) v právě definované struct („třídě“).
Virtuální dědičnost v C = vložení „zděděné“ „třídy“ (struct) do právě definované struct („třídy“).
Šablony jsou věc na úrovni zdrojového kódu, makra jsou, pravda, jen částečnou náhražkou. Metaprogramování v něm neuděláte.
Metoda = funkce (nejspíš začínající jménem „třídy“), v jejíž dokumentaci je uvedeno, k čemu slouží
Virtuální metoda = ukazatel na funkci v definici struct („třídy“).
Konstruktor/destruktor = funkce s _new a _destroy na konci názvu.
40znakový prefix znamená sice nepříjemnost při psaní kódu. Při čtení nebo ladění je rozhodně příjemnější, než dohledávání mezi desítkami definic přetíženého jména v C++.
No a díky GObject máte možnosti, kterými C++ objekdy nedisponují – posílání zpráv, nastavování vlastností objektu, čítač referencí.
Obliba C asi spočívá v tom, že:
Většina toho v C také jde, jen se to jinak píše a jinak nazývá: ...Já to znám, vím že to jde, ale otázka je, jestli vám přijde přehledné to takto dělat ?
Virtuální metoda = ukazatel na funkci v definici struct („třídy“).Takže:
struct A {
void (*method0)(A* self, int param0, int param1);
void (*method1)(A* self, int param0, int param1);
...
void (*method100)(A* self, int param0, int param1);
}
a v kódu:
A* A_new()
{
A* self = (A*)malloc(sizeof(A));
if (!self) return NULL;
...
self->method0 = A_method0;
...
self->method100 = A_method100;
}
Toto je podle vás dědičnost ? Toto jsou obyčejné ukazatele na funkce. V C se dá udělat dědičnost tak, že by se vytvořila další struktura, která by byla podobná té z C++ (virtuální tabulka funkcí), předpokládám, že jste to myslel spíš tak.
40znakový prefix znamená sice nepříjemnost při psaní kódu. Při čtení nebo ladění je rozhodně příjemnější, než dohledávání mezi desítkami definic přetíženého jména v C++.Já ladím pomocí nástrojů IDE, takže tento argument je úplně mimo. Nevšiml jsem si rozdílů mezi laděním C kódu a C++ kódu.
No a díky GObject máte možnosti, kterými C++ objekdy nedisponují – posílání zpráv, nastavování vlastností objektu, čítač referencí.Já mám na GObject jiný názor. Nastavování properties a události je věc, která není nativně v C/C++ a člověk si ji musí naprogramovat. GObject je řešení pro C, ale otázka je, jak moc kvalitní. A nemusím chodit ani daleko. Ukažte mi nějaký nástroj (code assist), který umí GObject, který je vám schopný ukázat, jaké máte možnosti. To samé pro vaši dědičnost v C a virtuální funkce v C ? jako nezlobte se, ale jestli vám přijde přehlednější toto:
GJmenoKnihovnyNazevObjektu *o = neco...; int x = g_nazev_zdedeneho_objektu_x_get(G_NAZEV_ZDEDENEHO_OBJEKTU(o)); int y = g_nazev_zdedeneho_objektu_y_get(G_NAZEV_ZDEDENEHO_OBJEKTU(o));než toto:
JmenoKnihovny::NazevObjektu *o = neco...; int x = o->x(); int y = o->y();Tak jsme asi oba někde jinde
Obliba C asi spočívá v tom, že:Jak jsem psal výše, to už není o oblibě, ale o držení se zajetých kolejí.
29.10.2008 17:44
Stanislav Brabec | skóre: 45
| Praha
Toto je podle vás dědičnost ? Toto jsou obyčejné ukazatele na funkce. V C se dá udělat dědičnost tak, že by se vytvořila další struktura, která by byla podobná té z C++ (virtuální tabulka funkcí), předpokládám, že jste to myslel spíš tak.Struktura, v ní virtuální tabulkou funkcí, a ukazatel na ní z nadřazené třídy. Prostě to, co udělá překladač jazyka C++ při kompilaci.
Já ladím pomocí nástrojů IDE, takže tento argument je úplně mimo. Nevšiml jsem si rozdílů mezi laděním C kódu a C++ kódu.Občas jen čtu kód a hledám, kde je definovaná funkce, která se vykoná. A to jde v C++ hůř, zatímco v C stačí
grep na hlavičkové soubory.
Já mám na GObject jiný názor. Nastavování properties a události je věc, která není nativně v C/C++ a člověk si ji musí naprogramovat. GObject je řešení pro C, ale otázka je, jak moc kvalitní.Třeba se dá se diskutovat, zda třeba řetězcové identifikátory vlastností jsou z hlediska efektivity ideální. A nemusím chodit ani daleko. Ukažte mi nějaký nástroj (code assist), který umí GObject, který je vám schopný ukázat, jaké máte možnosti. To samé pro vaši dědičnost v C a virtuální funkce v C ?
jako nezlobte se, ale jestli vám přijde přehlednější toto:Asi ano. První forma mi připadá přehlednější – myšlenkové úsilí potřebné na představení výsledné podoby kódu je nižší. Programování jsem se začal učit ve strojním kódu, později jsem se naučil assembler, teprve mnohem později C. C mi tehdy připadalo jako příliš vysokoúrovňový jazyk, ve kterém některé věci nejdou popsat přesně. C++ mi ve většině případů připadá jako zbytečná úroveň abstrakce dodnes (s výjimkou maticové algebry, komplexních čísel a podobných věcí).GJmenoKnihovnyNazevObjektu *o = neco...; int x = g_nazev_zdedeneho_objektu_x_get(G_NAZEV_ZDEDENEHO_OBJEKTU(o)); int y = g_nazev_zdedeneho_objektu_y_get(G_NAZEV_ZDEDENEHO_OBJEKTU(o));než toto:JmenoKnihovny::NazevObjektu *o = neco...; int x = o->x(); int y = o->y();Tak jsme asi oba někde jinde
Struktura, v ní virtuální tabulkou funkcí, a ukazatel na ní z nadřazené třídy. Prostě to, co udělá překladač jazyka C++ při kompilaci.Rozdíl mezi náma je ten, že já nechám překladač vyrobit tu tabulku a naplnit. Vy ji musíte definovat, napsat prototypy funkcí a pak při inicializaci knihovny naplnit pro každou třídu (strukturu) zvlášť.
Občas jen čtu kód a hledám, kde je definovaná funkce, která se vykoná. A to jde v C++ hůř, zatímco v C stačí grep na hlavičkové soubory.Já jsem zvyklý na "goto declaration" nebo "goto definition". Nemusím nic hledat, code assist to dělá za mě.
Třeba se dá se diskutovat, zda třeba řetězcové identifikátory vlastností jsou z hlediska efektivity ideální.Když se to udělá hash, tak jo :)
Asi ano...Vidíte, mi to přijde jako zbytečná redundance. Blbé je to, že jsem v tomto vlákně chtěl srovnávat jazyk C a C++ hlavně kvůli novým projektům. Nastolit otázku, zda se opravdu vývojářům zdá výhodné použít tento jazyk na dlouhodobé projekty. Nemusí to být ani otázka personálních preferencí, ale třeba otázka typu, zda je dostatek vývojářu pro konkrétní jazyk. O rychlosti vývoje ani nemluvím :)
29.10.2008 20:59
Stanislav Brabec | skóre: 45
| Praha
I tak je to stále komplikovanější, než unikátní identifikátor typu int. Ovšem v jeho případě by zase byl problém se zajištěním jeho unikátnosti, zvlášť v takových případech, kdy např. widget zdědí nějakou vlastnost specifickou pro určité grafické téma.Třeba se dá se diskutovat, zda třeba řetězcové identifikátory vlastností jsou z hlediska efektivity ideální.Když se to udělá hash, tak jo :)
Blbé je to, že jsem v tomto vlákně chtěl srovnávat jazyk C a C++ hlavně kvůli novým projektům. Nastolit otázku, zda se opravdu vývojářům zdá výhodné použít tento jazyk na dlouhodobé projekty. Nemusí to být ani otázka personálních preferencí, ale třeba otázka typu, zda je dostatek vývojářu pro konkrétní jazyk. O rychlosti vývoje ani nemluvím :)Podobné srovnání jsem sám pro sebe dělal před pár týdny při kursu C++. A došel jsem k závěru, že efektivní používání C++ (ale platí to skoro pro jakýkoliv jazyk) znamená nejen se daný jazyk naučit, ale také se naučit myslet v prostředcích, které ten jazyk nabízí. Druhý krok je výrazně těžší. Tomu, kdo umí C a učí se C++, připadají vymoženosti C++ vykoupené komplikovaností jazyka.
I tak je to stále komplikovanější, než unikátní identifikátor typu int. Ovšem v jeho případě by zase byl problém se zajištěním jeho unikátnosti, zvlášť v takových případech, kdy např. widget zdědí nějakou vlastnost specifickou pro určité grafické téma.Mnohdy je těžké zajistit i unikátnost řetězců, pokud se tedy unikátnost nezajistí stylem "prostorJmen-objekt-signal" (stylem dbus).
Podobné srovnání jsem sám pro sebe dělal před pár týdny při kursu C++. A došel jsem k závěru, že efektivní používání C++ (ale platí to skoro pro jakýkoliv jazyk) znamená nejen se daný jazyk naučit, ale také se naučit myslet v prostředcích, které ten jazyk nabízí. Druhý krok je výrazně těžší.Každý jazyk je potřeba se naučit
Já vidím problém hlavně v tom, že někteří lidi píšou o C++ nesmysly a ty se pak šíří mezi ostatní. Viz například FUD typu "C je rychlejší než C++". Když už tato věta odradí někoho od C++ a začne to šířit aniž by si vyzkoušel, co je na tom žvástu pravdy, tak je to těžké. Já si třeba myslím, že rychlost aplikace závisí hlavně na kvalitě ostatních komponent a na algoritmech v aplikaci, ale to sem pletu něco na co jsem odpovídal výše -- ale mám to pořád v hlavě
29.10.2008 22:01
Stanislav Brabec | skóre: 45
| Praha
Já si třeba myslím, že rychlost aplikace závisí hlavně na kvalitě ostatních komponent a na algoritmech v aplikaciTo je pravda. Stačí zevrubnější pohled do zdrojáku leckterého projektu (nebo jen do dokumentace API), aby člověku začaly vstávat vlasy hrůzou na hlavě. I v GNOME najdeme příkladů dost: Dialog pro výběr souboru ve starých verzích GTK+ četl aktuální adresář 6×. GTK Tree View Column nelze jednoduše učinit necitlivý na aktivaci řádku po kliknutí. Evolution ve svém původním návrhu u některých funkcí nepočítala, že by mohly selhat nebo nikdy neskončit. Při implementaci POP3 šlo o lokální operace, tak se to neřešilo. Problémy nastaly až při implementaci IMAP a trvají dodnes. Pidgin nadefinoval obecné API pro přenos souborů. Existující implementace se na to nějak nabastlily, a máme z toho pěkné CVE.
29.10.2008 11:49
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
Bez zajímavosti není ani pohled na programovací jazyky, které nové aplikace používají. Empathy je napsáno v jazyce C (stejně jako Vinagre a Cheese), Hamster používá Python. Nezdá se tedy, že by se v GNOME dostávalo většího prostoru jazyku C# (a technologii Mono obecně), jak by to mohlo vypadat z různých komentářů.Takhle bych na to nekoukal. Jak jsem různě četl, Gnome je otevřený všemu zajímavému, ať je to napsané v čemkoli. Kdyby byl Hamster v C#, tak by byl v C# a nic by se nezměnilo. Různí komentátoři v tom hledají politiku, ale ona tam žádná není.
30.10.2008 08:43
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
jen reaguji na názory, že GNOME migruje (stávající aplikace) do C#Tak to se mi opět vybavuje Miguelova odpoveď na to, jestli budou migrovat Evolution do C#, kde odpověděl, že ani náhodou, že ten kód trvalo vyvinout a odladit několik let, tak ho nehoděj přece jen tak přes palubu. To dává logiku a myslím, že podobné to bude i jinde. Migrace stávajících ne, ale nové aplikace, to je věc jiná.
29.10.2008 15:39
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
BTW:Screenshoty se mají vybírat
BTW2:Funguje někomu Ekiga či jiný SIP klient na VIPhone?
A zjistil jsem, že jsem nejproduktivnější ve středu v podvečer.Na tom něco určitě bude.
BTW:Screenshoty se mají vybíratNelíbil se mi ten stín...
29.10.2008 16:33
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
GIMP prý ale také vyšel v nové verzi. No, kdo ví…
29.10.2008 16:39
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
BTW2:Funguje někomu Ekiga či jiný SIP klient na VIPhone?Mně fungoval Twinkle, ale co jsem koupil HW telefon, tak jsem ho s tímto operátorem nepoužil (momentálně jsem u 802.cz a účet u Viphone si nechávám jen proto, že ho tam má i bratr a můžu mu tak volat zadarmo). Ekigu se mi kdysi taky podařilo rozběhnout, ale při provozu to porůznu padalo, takže jsem u ní nezůstal. Ovšem to je už tak dva - tři roky.
29.10.2008 21:00
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Od jiného operátora jsem to ovšem nezkoušel, takže nevím.
Nemůže to být tím, že se snažíte použít nějaký kodek, který Vifouni neumí?
30.10.2008 22:55
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
... osobně by mě zajímalo, kolik lidí hodnotí samotný článek, a kdo mě, Ubuntu atd.
A ani to moc neřeším, napsal jsem: "jen jsem zvědavý". Fakt mě to zajímá.
31.10.2008 14:16
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
29.10.2008 22:59
