OT: konecne poriadny piatkovy flame na temu "to C or not to C" Was:Vyctovy typ v C

[Jan Waclawek]

Jindrich Kubec wrote:
>>Napriklad gcc, rozdil je v chapani syntaxe, kdy jedna verze to preklada jednim
>>zpusobem, novejsi pak jinak (natolik jinak, ze vam to zbori aplikaci).
>>Proto napriklad u Firebird SQL serveru resi podporu vzdy konkretni verze.
>>Nebo tim, ze zapnete optimalizaci a vysledny kod se chova jinak, nez
>>s vypnutou optimalizaci.
> 
> 
> To je chyba jazyka nebo chyba implementace? <g>

Chyba jazyka, ktory svojou nejednoznacnou definiciou plnou 
nesystematickych prvkov (obvykle doprevadzanych argumentom "lebo je to 
take pekne") pripusta viacero interpretacii a tym viacero implementacii.

> 
>>Tim, ze je header textovy a zpracovava ho preprocesor (pri prekladu 
>>kazdeho souboru znovu)
>> tak preklad
>>rozsahlejsiho projektu je temer utrpeni (ano, ze vsech headu
>>se vytvori jeden obludny textovy soubor, ktery se finalne kompiluje).
>>Takze potom se resi takove veci, jako header cache atd.
> 
> 
> Precompiled headery.
> 

... narovnavak na vohejbak ...

> 
>>S timto take souvisi skutecnost, ze obj soubory nejsou samopopisne
>>a spatna verze headru a obj me stala nejedno odpoledne.
> 
> 
> To je ale jen neporadkem pri praci, to taky nesouvisi s jazykem. Zavislosti 
> *.h a *.obj by mel popisovat makefile. 

... co je len dalsi priklad ad-hoc zlepenca s prvkami sebaukajania 
vlastnou dokonalostou autora, ktory nezrozumitelnostou pouziteho 
zbytocne komplikovaneho postupu ukazuje svoju nadradenost nad obycajnym 
programatorskym plebsom...

Ak su nejake prvky vysledku prekladu navzajom zavisle, nevidim celkom 
pricinu ich nedavat do jedneho suboru.

> Takovy problem se mi nikdy nestal, 
> takze by me nenapadlo uvazovat o tom jako o problemu.

Problem, ktory _moze_ nastat, _je_ problem. To ze sa Vam nestal, nic, 
ale vobec nic neznamena (bez urazky, je to len vekmi (takmer som napisal 
wekmi :-) ) overeny fakt).

wek