Tak jakto že The C Programming Language od Kernighana a Ritchieho z roku 1978 zmiňuje preprocesor?
Zmiňuje preprocesor jako separátní tool. Těsnější integraci udělal AFAIK až clang. Pořád si pamatuju ten kvalitativní skok v chybových hláškách, když překladač najednou mohl vypsat i jména maker.
Některé lovy bugů si pamatuju fakt dobře, protože byly fakt drsné. Překladač vidí úplně jiný kód než vy a preprocesor vás ubije k smrti kvanty textu.
To je prosím celá mrtě logika, která je potřeba pro detekci endianity buildtoolem - ten checkne návratový kód.
...
Nee, ta logika je celý ten autotools ansábl, který ošahává překladač aby tím mohla nakrmit preprocesor.
Je to takové Cčkovské. V C můžeš udělat cokoliv, stačí když to celé uděláš sám. C ti hlavně nastaví vidle.
Přeložit a spustit testovací kousky programu a výsledkama nakrmit preprocesor by šlo použít u jakéhokoliv jazyka. C v tom figuruje jen tím, že nikde jinde takovéhle divočiny nepotkáte. Protože to dává smysl jen když nic lepšího není k dispozici.
C je všude, protože je navržený tak, aby se pro něj jednoduše psaly překladače. Všechno ostatní je tomu podřízené.
Linux je nejpřenositelnější OS jaký existuje 
No a nemyslím si že používají GCC kvůli tomu že by C nebylo přenositelné.
Inline assembler je spíše praktická věc pro OS kód. Různé builtin funkce jsou spíše optimalizační techniky. Makro typeof zase umožňuje generičtější kód, což jenom šetří psaní... dalo by se bez toho všeho obejít. Které věci z GCC dialektu jsou striktně kvůli přenositelnosti bez kterých by se nedalo obejít?
Dialekt není jen o rozšířeních. Je třeba i o zalepeném nedefinovaném chování. Váš kousek kódu může mít nedefinované chování kvůli aliasingu. Ve standardním C by se to muselo napsat jinak. Ale autotools samozřejmě řeší přenositelnost jen v rámci gnu světa.
Poslední příspěvky
