Kdyby autoři BeoSu nebyli blbci, tak BeOS dnes existuje a je rozšířen.

Sebevraždu BeOS spáchal zhruba tímto počinem „nebojí se v každé další verzi BeOSu nekompatibilně měnit API operačního systému“.

Autory programů dlouho nebaví neustále přepisovat aplikace, kdykoli se autoři BeOSu rozhodnou.

Takže v určitý čas se mnoho programů portovalo na BeOS, ale ono to lidi nebaví dlouho.

Stejnou sebevraždu spáchal Perl, stejnou sebevraždu pomalu páchá Python. Oba se dočkají svých plodů takjako se dočkal BeOS.

Cpát do jednoho pytle BeOS a Python mi přijde ujeté, ale budiž.

BeOS se dostupným pro normální uživatele stal velmi pozdě, dobrý systém byl dlouho svázán s konkrétním hardware a špičkových systémů, které potkal podobný osud je neúrekom (RiscOS, AmigaOS). Od roku 2001 jej dělají nadšenci a oproti *BSD, či GNU/Linuxu nemohou vyvíjet tak aktivně a s takovou podporou HW.

Mimochodem, zaplať Pán Bůh za pročištění API a jazyka Python i Perl, bylo tam historicky takového bordelu z vývoje, až to nebylo možné. Nastal čas, kdy bylo potřeba udělat radikální řez.

BeOS i jeho boom jsem zažil na vlastní kůži.

Vím, proč skutečně neuspěl. A to prosím na straně uživatelů o něm byl takový zájem, že jsem valil doslova bulvy – rozhodně mnohem vyšší,než o Linux a uživatelům se BeOS velmi líbil.

Je sice hezké, že uvádíte, že řadu dalších os potkal osud zapomění, nicméně BeOS tam být nemusel. O ten os byl zájem a ani uživatelé ani vývojáři aplikací ho neignorovali. Na rozdíl od řady jiných os. A že neměl takovou podporu hw? Který os na začátku má? Je to jen otázkou času a nebylo tak zlé aby to lidem vadilo. A lidi jsou ten konečný soudce, ne filozofické teoretizování o jiných os. BeOS srazilo jen a pouze to, že udělal to co Python a Perl – nekompatibilně měnil API a přidělával tak spoustu starostí výrobcům aplikací (kterých bylo hodně) až se na BeOS vybodli. A bez aplikací žádný os nemá smysl.

Python jako takový si pročištěním API vykopal hrob, jen bude pár let trvat, než to bude zřejmé. Chcete se vsadit? Nemůžu prohrát.

Pročištění Pythonu a Perlu byl takový pokus a později to bude příklad toho, jak si jazyk sám pod sebou podřeže větev. Třeba takový Python to udělal po 17 letech existence a to je trochu jiná káva. Ale historie potřebuje příklady jak věci nedělat a v případě Pythonu ho dostane.

Zajimave je, ze prakticky vsechny dnes hojne pouzivane programovaci jazyky prosly nejakou zasadni nekompatiblni zmenou, v nekterych pripadech dokonce vicekrat.

Namatkou a po pameti:
C++ - namespaces (a o zpetne/dopredne/vzajemne kompatibilite jakehokoli API v C++ jsem se tu uz tusim nekolikrat vyjadroval)
Java - CNI vs. JNI, "Java2", Java5 class file format
CLR - prakticky s kazdou verzi .NET frameworku se neco podstatneho nejak zmeni
Python - MRO, "great renaming"
PHP - ma to smysl vypisovat? :)

Zaver: pokud chcete naprostou zpetnou kompatibilitu, programujte v COBOLu pro System z.

C++ neprošlo žádnou změnou. Dosud je platný pouze jeden jediný standard C++ z roku 1989.

Pokud jste se nějak vyjadřoval ke změně API v C++, tak už to prosím nehulte.

C++ má jediný ISO standard, tudíž ani jednu změnu. Když tedy tvrdíte o změnách ve stabdardbím C++, tak evidentně nevíte, která bije.

Změna v C++ se připravuje jako budoucí standard C++0x, a zde se tvrdě dodržuje zpětná kompatibilita, tedy kompatibilita se současným C++ standardem. Až velmi úzkostlivě.

Dále se nevyjadřuji, protože evidetněn víte kulové a nemá smysl reagovat na někoho, kdo reaguje v rámci sebevědomí, ale nikoli znalostmi. Sebevědomí lidé, kteří nic nevědí – to je nový trend.

A jak vidím, vyjadřoval jste se již v minulosti o své blbosti (viz změny a kompatiblita v C++ API, o které jste se již vyjadřoval). Přeji Vám, abyste jednou znalostmi v budoucnu vyrovnal Vaší touhu komentovat i když se ztrapníte.

"C++ neprošlo žádnou změnou. Dosud je platný pouze jeden jediný standard C++ z roku 1989."

Uz jenom toto tvrzeni dokazuje, ze o tom vite kulove vy. V roce 1989 opravdu zadny standard C++ nebyl vydan (nepleteta si to s ANSI X3.159-1989 "Programming Language C"?), zato doslo k prvni vyraznejsi revizi jazyka jako takoveho (a zpetna kompatibilita byla porusena, kdyz uz ne jinak, tak pridanim klicoveho slova protected). Samotne "standardni C++" je zalezitost az vyznamne pozdejsi doby. Prvni formalni standard je ISO/IEC 14882:1998, ktery byl pozdeji revidovan jako ISO/IEC 14882:2003. Mezi C++ tak jak bylo v 90. letech prakticky implemenovano a pouzivano a ISO/IEC 14882:1998 jsou velmi zasadni rozdily, coz je presne ta nekompatibilni zmena na kterou jsem narazel. Mnohe vyznamne projekty psane v C++ existuji daleko dele, nez standard, coz se projevuje dokumenty tohoto typu: https://developer.mozilla.org/en/C___Portability_Guide (zajimave je, ze to nekdo nadale udrzuje a zatimco nektere polozky relevantni v dobach pred ISO C++ byly odstraneny, tak jine zase pribyly)

A ohledne tech stabilnich rozhranni v C++: ten BeOS je skvelou ukazkou toho proc je spatny napad mit cokoli, cehoz rozhrani je definovano v C++. Ve chvili kdy ledasjaka banalni zmena v implementaci (treba zmena typu nejakeho slotu) vyzaduje rekompilaci uzivatelskeho kodu idealne stejnou verzi kompilatoru, tak opravdu neni realne mozne se z tohho nezblaznit (pokud mi chcete tvrdit, ze se C++ tak nechova, tak si to zkuste, pripadne najdete nejaky "standard", ktery toto chovani zakazuje). Mimochodem, kdyz uz jste zminil ten Python. Vite co je nejvetsi problem pri distribuci pythonovych modulu pro Windows? Navzajem nekompatibilni kompilatory C++ (a v pripade msvc prehrsel banalne znejicich voleb, ktere meni ABI).

Myslim si, ze vas zasadni problem lezi v tom, ze jste jeste na zadny takovy problem nenarazil, mozna proto, ze jste jeste nikdy nemel potrebu mit program v C++ jinak, nez jako jeden velky spustitelny soubor.

Jo jo, tak jste mě uvařil na překlepu v posledních dvou číslicích roku. Gratuluji Vám. Doufám, že se cítíte jako king.

Jinak platí, to co jsem psal, existuje standard C++ z roku 1998 + korekce 2003. A ten je závazný. Pokud někdo programoval v C++ před ním, věděl, že programuje bez standardu. Tak jak jsem to roky dělal já. A také jsem věděl, že ten standard musí přijít.

Dnes už navíc existuje C++11.

---

Žádný běžný programovací jazyk nedefinuje ABI. Stejný problém, který popisujete v C++ jako rozhraní existuje i v C. Stejně jako v jakémkoli jiném programovacím jazyce. To, že na programovací jazyk kladete požadavky, které vám žádný jazyk nesplňuje je problém vašeho přehnaného očekávání.

C++ objektové rozhraní samozřejmě definovat a používat jde. A není třeba k tomu kompilovat něco stejnou verzí kompilátoru. Například Microsoft jich takto definuje celou řadu objektových rozhraní ve formě COM. Třeba celé DirectX na to závisí.

Nemohu za to, že problému nerozumíte. Že si navíc pletete ABI modulů pro linker a ABI rozhraní knihoven či operačního systému. Ono vás v tomto stylu uvažování nakope do zadnice i C, když budete používat cokoli mimo int a pointery v knihovních rozhraních.

Samotna existence COM ukazuje, ze pouzit jako rozhrani primo nativni datove struktury v C++ nelze. COM pomerne elgantne resi stabilitu rozhrani tim, ze vsechno je budto nepruhledny pointer nebo pole pointeru na neco (typicky funkci). Odstranuje tim tedy jakykoli problem s manglovanim nazvu (linker-level nazvy symbolu nejsou pro COM zajimave) a dokonce i s rozlozenim dat v pameti (zadna "data" nejsou primo pristupna).

U cisteho C to ABI neni zas az tak zajimavy problem, protoze na rozumnych platformach je obvykle jedno jedine (reprezentace hodnot v pameti byva obvykle jedna optimalni a rozumny system ma jenom jednu bezne pouzivanou volaci konvenci, uz jenom proto, ze je potreba volat take do knihoven OS). Druha vec je, ze int, nepruhledny pointer (typedef struct foo_s foo_t; a foo_s definovane mimo header) a pointer na pole bajtu je tak zhruba vse co je na rozhrani modulu fakticky potreba.