zmaten z gcc, glibc...

[Ing. Pavel PaJaSoft Janousek]

> Linus jasne prohlasil, ze dokud nevyda "nejaky" distributor ext3 ve sve
> distribuci, nebude ext3 prijato (a taky tam neni). V jadrech od RH jsou

	A toto je jedna z vecich, ktere si myslim ve vyvoji urciteho software
nema existovat - je to dobra komponenta nebo je to komponenta, ktera
ceka na to, az bude komercne (nemysleno financne) uspesna? Merit
chybovost ci bezchybnou funkcnost software tim, ze ji nekdo zaradi do
svych distribucnich kanalu (vubec nemusi jit o komerci, proste ji nekdo
zacne pouzivat) se pro mne dost tezko akceptovatelny pristup.

> Problem asi bude take v tom, ze norma jazyka C++ se dost menila a nemela
> jednotny vyklad. Pokud jsem dobre koukal, u GCC 3.0 se psalo, ze
> implementuje 'almost all' z norem pro C++, takze je to asi skutecne
> slozite (osobne v C++ neprogramuji, jen jsem cosi opravoval).

	Tak uz snad po ste... - zadna norma jazyka C++ se nemenila, ona
__NIKDY__ zadna neexistovala! Vse co existovalo v nekolika verzich byl
navrh normy v ramci pracovni standardizacni komise, ktera se k nemu
vyjadrovala a pravdepodobne mela dost dobre duvody, proc delala zmeny
mezi jednotlivymi draft verzemi normy (napr. neco si usnesna, zkoumalo
se dale a zjistilo se, ze to co se na prvni pohled zdal jako dobry napad
je uplna blbost - evoluce funguje vsude; pokud to same, ale skutecne v
norme provedlo W3C - mluvim o HTML Look ala <font> apod. mezi verzemi
3.X a 4.X (kde je uz zase vsechno deprecated a presunuto do CSS kam to
vzdy a pouze jen tam melo patrit)  mnoho lidi to neudivuje). To, co se
drive bralo jako norma C++ (ac ji nebyla) byla jedna konkretni
implementace jazyka C++ v podani pana Stroustrapa (nikdy nevim, jak se
dotycny pan presne jmenuje :-]) v konkretnim kompilatoru dodavaneho AT&T
ve verzi 2.0, pozdeji 2.1.

	Vis kolik existovalo meziproduktovych navrhu nez bylo HTTP/0.9
aktualizovane na HTTP/1.0, pozdeji na 1.1? Pokud nekdo implementoval
neco z navrhu (bez podpory alespon v RFC) HTTP/1.0 a ve finalni podobe
(RFC 1945) je to receno jinak (klidne treba jen otoceni logiky stavu),
je to ciste jeho problem a je to chyba. Presne to same se totiz delo s
normou jazyka C++ - nikoho neprekvapi, ze mame HTTP/0.9, HTTP/1.0 a
HTTP/1.1 - 'WWW' komunikacni protokol jasne definovany v trech na sebe
navazujicich RFC a jestli bylo mezi tim spousta draftu, ktere nekdy sli
proti sobe nikoho to nezajima, proc by to melo zajimat aplikacni
programatory v C++? Chteli novinky nikde nestandardizovane? - budiz,
odpovednost (a naklady) musi nest sami ... - vis napr. ze v C je
komentar ala (C++) // je az v ANSI C99 a do te doby to bylo rozsireni...
a vis, mnou oblibeny tento komentar, ze jsem narazil i loni? Dobre mi
tak....

> BTW: proc se bavime vlastne o kompilatoru jako o problemu, kdyz se
>      porad narazi na komercni aplikace, ktere si zakaznik sam
>      nepreklada? ;-)

	To bude nejspise tim, ze v tuto chvili pokud dobre chapu situaci
neexistuje neco na zpusob *.EXE formatu z MS DOSu - je uplne jedno,
zda-li byl kod prekladan v roce 1979 (zamerne uvadim datum starsi nez
vydani MS DOS 1.0 v roce 1981) a vzniklo neco, co melo zaklad v CP/M
nebo v roce 2001 VC++ 6.0 (+ patches) - pokud jsem zvolil spravny
instrukcni soubor (I8086), nemam problem v prostredi MS DOS ci
'nastupnem' MS Windows takovyto program spustit (prosim, nechytat za
slovo pri I/O spolupraci s periferiemi na urovni portu apod. - moc dobre
vim, pokud jsou moje slova pravdiva). Takovato situaci, ktera je IMHO
velmi potreba v ELF formatu (myslim, ze vychazi z COFF), bohuzel
neexistuje... - pokud aplikaci skompiluju v RH 7.X, tezko ji spustim v
RH 5.X ci jine distribuci starsiho data nez rekneme max. rok dozadu... -
neni v necem chyba?

	Drive slo zkompilovat veci ciste staticky a pak ani v UNIXech (pravda
binarka mela radove MB a vice) nebyl problem - kolik knihoven je dneska
dodavano tak, ze existuji obe alternativy? Ja si rovnez myslim, ze je
velka vyhoda kompilovat dynamicky a vyuzivat dynamicky linker, ale ta
dan, kterou za to platime neni ekvivalentni a uz vubec ne nutna...

> Kazda zmena minor verze meni rozhrani a je snaha je zachovat uvnitr
> jednotlivych zaplato-verzi. Podle mych vzpominek to ale neni 100% pravidlo
> a je to proste fakt.

	No to je fakt s prominutim pekny bordel, jiz v drevnich dobach vyvoje
software bylo nepsane pravidlo, ze takoveto zmeny jsou vysadou max. tzv.
Major verze, minor slouzi predevsim k doladeni funkcnosti, opravam,
zpetne kompatibilnimu rozsireni apod. - ne ke zmene rozhranni... mas
jiny nazor?

-----------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)                 FoNet, spol. s r. o.
Vyvoj software, Intranet / Internet          Anenska 11, 602 00  Brno
E-mail: mailto:Janousek na FoNet.Cz             Tel.: +420  5  4324 4749
SMS:    mailto:P.Janousek na SMS.Paegas.Cz      Fax.: +420  5  4324 4751
WWW:    http://WWW.FoNet.Cz/               E-mail: mailto:Info na FoNet.Cz
-----------------------------------------------------------------------