Názory k článku Nové Ubuntu má vážné problémy s grafikami Intel

Co ma C++ navic oproti C? Nic, co by se nedalo poresit makry v C (pretizene "funkce", sablony, polymorfismus). Navic v C to muzete lepe zoptimalizovat.

Co má C navíc oproti assembleru? Nic, co by se nedalo pořešit makry a navíc to můžete lépe zoptimalizovat. Přesto raději píšu v C++.

static MyObject *singleton = 0;
char buff[sizeof(MyObject)];

MyObject getSingleton() {
  if (singleton == 0) singleton = new(buffer) MyObject();
  return singleton;
}

Pardon, ale tento příspěvek je jeden obrovský kec člověka, který tomu vůbec nerozumí

-volání callback funkcí je jednodušší než ošetřování tabulky funkcí

volání callback funkce se zpravidla dělá ukazatelem na funkci. Tabulka funkcí má tu výhodu, že s objektem většinou stěhujete jeden ukazatel, nikoliv celou (callback) tabulku (pokud je těch callbacků víc). Když narvete callbacky do struktury, uděláte to přesně tak, jak to dělá C++

-žemusíte dokonce brát ohled na to, zda daná fukce je přetížena (a jak) či ne

To nemusí nikdo, to se řeší při překladu. Program už jen koukne do tabulky a volá (výpočet má složtitost O(1))

-že při startu aplikace je všechno už nachystané

Proč pořád opakujete tuhle pitomost!!!!!!

Ale tohle je fakt síla:!!!

"C++ vám sám nezavře zdroj,ani neuklidí paměť (to spíš Java), Většinu z toho pokud si ještě něco pamatuji dělá zase systém při ukončování aplikace"

Proboha člověče, nekecejte do něčeho, čemu nerozumíte! Tohle je úplný blábol! Svatá dobroto!

:-DDDDDDD

To jsem nepochopil

Opravdu? To je velmi zajmavé, protože mě vždycky učily, že každé new musí mít své delete. Jinými slovy mohl by jste mi říci, který standart říká, že C++ má autonomní zprávu paměti a systémových zdrojů?

RAII znáte?

No pokud to správně chápu, tak k tomu potřebujete podporu kompilátoru, protože ten tu dealokaci hlídá (popř, mechanismy vložené kompilátorem do aplikace) statických objektů, ne?

Ano, potřebujete k tomu podporu kompilátoru, aby vložil na správná místa stack unwind (kde se provede volání destruktorů a tedy i dealokace). Ale to je součástí ISO C++. Žádnou extra podporu nepotřebujete.

Jinak to, že pokud si alokaci a dealokaci zdrojů hlídám sám, znamená to, že jsem prase? Od toho je přece konstruktor a destruktor...

A přesně to je RAII.

Dokonce jsem se tu i zmiňoval o tom, že pomocí inteligentních ukaztelů a pod si zprávu paměti udělat můžete

Ne můžete, musíte! Jinak si zaděláváte na problémy! Po silnici taky můžete jezdit jak chcete, ale přeci jen je výhodnější dodržovat nějaká pravidla silničního provozu!

(To ovšem nemusí znamenat, že to všichni musí považovat za řešení pro jádro, a že to musejí asgerechnet použít. A už se vám to líbí nebo ne)

Samozřejmě, debilové se najdou i na silnici. Ale ani tady nejste na holičkách. Pokud někdo nějaké prostředky uvolňuje jinak, než pomocí new a delete, máte šanci upravit chytrý ukazatel a přizpůsobit se tomu. Na opačně straně rozhraní, pokud vy poskytujete chytrý ukazatel, můžete také poskytnout jeho raw verzi s tím, že dáte uživateli vašeho kódu i funkc na destrukci toho objektu. Ale ztratíte výhodu automatické správy zdrojů. Ovšem to co se snažím tady celou dobu říct a zřejmě mě nebylo stále pochopeno. C++ není jen jazyk a navazující knihovna STL. Ale taky soubor vzorů (patternů) a mnoho doporučení, jak v C++ programovat. Za velice zdařilou stránku věnující se této problematice považuji tuto: c++ Faq Lite. C programátoři budou prskat, oni si programují, jak jim "zobák narostl". Pak ten kód vypadá jak vypadá!

Takže suma sumárum, v C++ si programujte jak chcete. Ale nesmíte se divit, že budete za prase. A protože přemíra prasat v C/C++ je neudržitelná, nikdo si nelajzne přecházet s jádrem do C++. V tom vidím celý problém. Technické, či výkoností problémy jsou jen virtuální chimérou sektářského popíračtví, že jádro nelze psát v C++. Jde a bez problémů! Dokázal bych si představit celý OS v C++, od zavaděče až po ovladače, správu paměti a GUI. Bohužel nemám čas se tomu věnovat

Je otázkou proč psát kernel v C++. Výhod je minimum. Naopak kernel v C# (Singularity) nebo Javě může přinést výhod velkou hromadu.

void *operator new(size_t sz, int flags) {
   return kmalloc(sz,flags);
}
void operator delete(void *ptr, int flags) {
   return kfree(ptr);
}
void operator delete(void *ptr) {
   return kfree(ptr);
}

{
  Object *x = new(GFP_KERNEL) Object(...);
  ...
  ...
  delete x;
}

což v tomto případě znamená i volání funkcí navíc

Ale kdepak, tyhle funkce kompilátor inlineuje

Nevidím v tom moc praktický účel.

STl kontejnery, Boost, polymorfní ukazatele... Ono je toho poměrně dost, co ty operátory využije a může se i v jádře hodit.

Ovladače pro Linux jsou odvozené od kernelu, pokud obsahují některé jeho části. Jak určitě víte, tak třeba ovladače od fy. nVidia odvozené dílo nejsou.

Zaměňujede příčinu a následek. Příčina zamítnutí pevně daného ABI byla úplně jiná a jako následek bylo doporučeno ovladače poskytnout přímo vývojářům jádra (protože ti potom zaručí, že to bude fungovat i v novějších verzích). Pokud to ale neuděláte, tak je většina vývojářů poměrně ochotná vám poradit nebo i pomoct s vývojem out-of-kernel (buď pod GPL nebo za peníze).

Drivery neobsahují části kernelu. Nejvýše volají některé funkce kernelu, a nabízejí interface volaný kernelem.

Možná ve Windows, kde vlastně ani nemůžou, ale v Linuxu moduly docela často obsahují kód z jiného modulu a všechno to je v repozitáři kernelu. Pokud chce někdo vyvíjet vlastní modul, který nebude pod GPL, tak s tím může mít problém.

Ty údajné důvody pro odmítnutí stabilního ABI jsou směšné. Ve skutečnosti je za tím chaotický návrh, a snaha protlačit otevřené ovladače házením klacků pod nohy každému, kdo by chtěl jít jinou cestou. Pro uživatele to znamená velkou řadu komplikací, ale proč nepoložit uživatele na oltář otevřeného kódu.

Ano, jistě to všechny ty *Ex a Ex* funkce a rozdíly v chování starších API oproti starším verzím Windows v MSDN ví daleko lépe než samotní vývojáři.

Pobaví to "pod GPL nebo za peníze". Prakticky celý kernel Linuxu je pod GPL, ale napsaný za peníze. Viz Linux Foundation.

Co vás na tom pobaví? Tady máte alespoň na výběr mezi GPL nebo placením. U MS máte k dispozici jen to placení.

Drivery nemusí obsahovat žádný kód kernelu. Samozřejmě pokud použijete cut and paste kus kódu z jiného driveru, je to jiná. Jenže vývojáři jádra tvrdí, že podle nich KAŽDÝ kernelový modul pro Linux musí být uvolněn pod GPL.

To někteří fanatici skutečně tvrdí, ale někteří fanatici tvrdí, že Windows jsou vzor zpětné kompatibility :) Většina nemá s proprietárními ovladači problémy, pokud opravdu nejsou odvozené dílo.

*Ex a Ex* funkce prostě rozšiřují API. To přece není nic špatného. Nebo byste chtěl místo toho rozbít zpětnou kompatibilitu? Já zapomněl - už jste ukázal, že takový koncept je vám cizí.

Zpětná kompatibilita uvnitř jádra mě opravdu moc netrápí a argumenty proti mi připadají vhodné (samozřejmě jiná je situace u Windows, kde MS hodil tvorbu ovladačů jen na výrobce). Zpětná kompatibilita v user space je zachovávána.

Taková zpětná kompatibilita nemá na Linuxu obdobu ani náhodou. Každá aplikace se muís balit pro každou verzi každého distra. A pro novou verzi distra znovu kompilovat, znovu balit...

To jste asi nepochopil, jak funguje zpětná kompatibilita v Linuxu. Linux je založen na POSIX a tam je explicitně uvedeno, že kompatibilita je zaručena jen pro zdrojové kódy, ze kterých se vybuildí aplikace pro příslušný systém a hardware, což je to výhodně, můžete ten program jednou napsat a přeložit na deset různých platforem a může být lépe optimalizován při překladu pro určený systém nebo přímo hardwarovou konfiguraci (což je extrémně důležité pro embedded systémy).

Za práci se platí. To fakt nevíte?

Vám někdo platí i za koníčky?

Nicméně soubor v adresáři smažete. A k čemu to vede? Aplikace otevře soubor /dir/file, a začne z něj číst threadem A. Uživatel smaže /dir/file, a na místo umístí úplně jiný soubor toho samého jména. Aplikace threadem B otevře soubor /dir/file, a začne do něj zapisovat data, které čte threadem A. Hm, všechno je v háji, data zničená...

Když ale někdo napíše tak blbou aplikaci, že si neumí předat file handle z jednoho threadu do druhého, tak to není vina systému. Krom toho na takovou aplikaci bych spíš použil pipe a na filesystém vůbec nesahal.

Pokud zavedete najednou novou i starou verzi knihovny, může to vést k závažným problémům. Představte si třeba DB engine, který pomocí knihovny přistupuje k databázovým souborům. Spustí nový worker proces (na unixech tradiční věc), ten zavede novou knihovnu, a průšvih je na světě.

Worker proces nemá co zavádět knihovny. To má dělat master proces. A ten může také knihovny reloadovat, pokud se změní (třeba Apache to tak dělá při graceful-restart).

Ve Windows navíc při instalaci můžete běžící aplikaci říci, že má uložit svůj stav (u Office otevřené soubory, stav oken apod), a po restartu aplikace či celého stroje se má obnovit v posledním stavu.

To není nic navíc, tohle KDEčka umí už ... no hodně dlouho.