Go 1

A C egy többé-kevésbé platformfüggetlen nem túl vastag rétegként készült az assembly fölé, kernelhekkelési célzattal. Bármiféle modulkezelést beépíteni már tökönlőtte volna ezt a célt. Az egyszerű szövegmásolás teljesen jó megoldás ilyen szinten.
----
Hülye pelikán

+1

személyes kedvencem anno a turbo pascal .tpu megoldasa volt.

az is nagoyn jo volt plusszban, hogy ha bele kellett nezni a forrasba, remekul elkulonult az interface es az implementation resz, s egybol lattad az interface-ban, hogy mi van a .tpu -ban. nem ugy, mint egy c .h-ban....

A C fejlesztésénél eredetileg nem számítottak arra, hogy ennyire el fog terjedni. Arra sem számítottak, hogy ilyen hatalmas programokat fognak benne írni. Rövid programoknál pedig kézenfekvő az #include-os megoldás már csak azért is, mert az egyes programrészek fordítása jól elkülöníthetővé válik a teljes programétól. Ez szépen illeszkedik a Unix-os világképbe azzal, hogy az egyes munkafázisokat végző programok egyszerűek maradnak és nem kell a különféle fázisoknak belelátniuk egymás működésébe. Ma már ez nem probléma, mert a C fordítók is lényegesen okosabbak lettek és a számítógépeknek is több tartaléka van. Azonban akkoriban a kevés memóriával rendelkező gépeknél a feladatok izolációja logikus lépés volt.

Egyébként semmi baj nincs az include-dal ha valaki tudja helyesen használni a nyelvet. Sőt, nekem pl. kifejezetten természetesnek tűnik egy ilyen megoldás. Rendszerprogramozáshoz LÉNYEGESEN jobb megoldás mint bármi más, mert sokkal nagyobb betekintést nyújt abba, hogy mi történik a háttérben. Grafikus programokhoz már nem ideális, de igazaból a C-t sem kéne arra használni.

Kösz, nem igazán használtam xor-t assembly-n kívül máshol kb. 15 éve. Viszont **-al sem tud hatványozni ahogy látom, vagy egyáltalán nem tud hatványt ezek szerint? Vagy külön math függvényt kell hívni? Ez érdekelne. Ha valaki elárulja, azt kösz.

Azonos logikával a } is kerülhetne egy sorral feljebb. Ízlés dolga, bár tény, hogy ennyivel kevesebb dolgot kell lefixálni a kódolási konvenciókban. Másrészről viszont a kódolási konvenciókban általában logika van, emiatt a kényszerítésük szerintem nem jó dolog. Éljen a Perl!!! :-)

Az if az end if-fel, a kapocs a kapoccsal van párban.

És sokkal esztétikusabb is úgy.

Ez merőben vallási vita, kinek így, kinek úgy tetszik, pont azért eldönthetetlen, mert mindkettő mellett jó érvek szólnak. Az a fontos, hogy egy projekten belül egységes legyen. Az nem tetszik, hogy a nyelv rámkényszeríti, a whitespace kevés kivételtől eltekintve mindig is olyan volt, hogy szabadon lehetett vele bánni. Ez az érvelés, hogy a lexernek előre kell olvasnia... mi? A lexer átugorja a whitespacet, legyen az szóköz, tab vagy újsor, neki aztán rohadtul mindegy, hogy hol van a nyitózárójel, azon a soron vagy a következőben.

Amúgy valaki elmondhatná, hogy mennyiben jobb ez a nyelv, mint tetszőleges komolyabb scriptnyelv (Python, Ruby). Ha azokhoz írt volna a Google egy jó kis fordítót, előrébb lennénk.
----
Hülye pelikán

a célközönség nagyrésze valószínűleg hozzá van szokva

Hozzá lehet több szintaxishoz is szokni párhuzamosan, szóval ez nem egy kardinális kérdés.

Miert, a C# moge nem kell a framework? Szvsz ez nem hatrany.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Hát amikor azzal kell baszakodni, hogy mikor foglalok le memóriát és mikor lehet, illetve mikor kell felszabadítani, az nem high-level programming.

Amikor az emberek C++-ban szeretnének magas szinten programozni, akkor jellemzően orrba-szájba használnak smart pointereket, de ...

a) azok csak a takarítás terhét veszik le (részben) az ember válláról, tehát csak a GC feladatát látják el (részben). A managed memory ennél több, a GC mellett a védelem is része, amely egyrészt meggátolja, hogy hülyeséget csinálj, továbbá több segítséget ad a hiba azonosításához és javításához.
Például C++-ban bármilyen hiba jelentkezhet SIGSEGV formájában, míg Pythonban segmentation violation egyszerűen nem lehetséges. Persze van Pythonban is run-time error, de ott elsőre valami értelmesebb hibaüzenetet kapsz.

b) nehézkes a használatuk. Van vagy féltucat féle smart pointer (auto_ptr / unique_ptr, scoped_ptr, shared_ptr, weak_ptr, ...) aminek a használatát meggondolhatod. Jó, persze ezek nagyrésze pusztán teljesítmény-optimalizáció, és ha magas szinten akarsz programozni, akkor egyszerűen mindig shared_ptr-t használsz, de ez sem jó: a hivatkozási körök ellen nem véd, így ha nem akarsz memory leakes programot kiadni, akkor át kell gondolnod, hogy lehet-e kör a hivatkozásokban, tehát a probléma megoldásán túl továbbra is muszáj a memóriakezelésen baszakodni.

Beágyazott rendszerekre. Olyat mondjuk nem írtam még, de nem hinném, hogy arra alkalmazást fejlesztenének, és nem rendszert.

Szerk:
"Az ADA GC-je annyi, hogy amikor kimegy scope-ból a pointer, akkor minden olyan típusú ojjektumot felszabadít. Azért ezt GC-nek nevezni erős."

Ez sem mindig igaz, mert ha a típusa nem kerül ki, a pointer sem (pl. láncolt lista elemeinek a típusa). Így "kézzel" kell felszabadítani, explicit módon.