Teda aspoň by ty programy mohly mít slušnou (trošku explicitnější) deklaraci main()... :-p K čemu pak člověk ty začátečníky vychovává? ;-)
Jo, zdá se mi to, nebo malloc a free nejsou deklarovány v stdio.h? Samozřejmě i to může spadat do té "smysluplnosti", se kterou se prý nemám zabývat...ale přece. :-)
ACK^3, bez toho je to totální katastrofa. Dokonce někdy studentům doporučuji i -pedantic, aby si zvykali na přenositelné Céčko.
Trocha stránek s příklady, úkoly a krátkými návody, které jsme připravili na cvičení programování v C pod Linuxem, je na následující adrese
Rádi si vyslechneme Vaši kritiku, nápady, či odkazy na podobně zaměřené stránky.
"ale o C bych nikdy jako o multiplatformnim jazyku nemluvil. - uz treba proto, ze kod je potreba pro kazdou z platforem znovu zkompilovat ;)"
Vždycky je třeba něco pro každou platformu zkompilovat.
Jo a Cčko má svůj abstrahovaný virtuální počítač... :-) Že se nejedná zrovna o bajtkód s pevnou binární formou, to bych až tak neviděl jako problém. To už spíš požadavky na standardní typy by mohly být jednotnější, ale zase C99 spoustu věcí řeší.
Potvrzuji, zároveň i programátoři v Javě, grafických blocích v Simulinku nebo LabView, by měli znát základy zpracování programu obecným procesorem a měli by vědět, co je to adrsový prostor, jak vypadá běžné pole atd. Bez těchto znalostí programují takové zrůdnosti a obludy bez rozmyslu. Právě dobře programovat ve vyšších jazycích znamená být si vědom, jakým způsobem a za jakou cenu takové prostředí vyšší konstrukce přeloží. Pro lidi, kteří mají zájem o programování řídicích aplikací či jader operačních systémů, je znalost jazyka C nutností. Pár důvodů jsme sepsali třeba zde. Rádi si vyslechneme prípadné námitky.
Na druhou stranu souhlasím, že pro lidi, kteří programují jen občas nebo se teprve učí návrh algoritmů pochopit, není jazyk C vhodný. Python, Java nebo C# je asi vhodnější.
Program se má s učením se nových konstrukcí rozšiřovat, ne přepisovat.
2) Pokud vím, tak např. Mac OS je napsán v Object C, což je ale jiná káva než Céčko! :-)
Nemohu si pomoct, a musím reagovat. MacOs X je postavený nad mikrojádrem XNU (MACH 2.5 + BSD + I/O Kit). Základní dva prvky jsou, pokud se nemýlím, čisté C. I/O Kit využívá embedded subset C++. Jinak plně s předchozím nepodloženým výkřikem souhlasím v tom, že vyšší vrstvy GUI, práci s databázemi a aplikace je rozumné psát v něčem objektovějším než je C. Ale na kvalitně optimalizovaná jádra je zatím asi C nejlepší. Nakonec i ty pisatelem tak propagované Windows jsou napsané objektově v čistém C. Stejně jako Linux, HURD, BSD a mnoho dalších systémů. Je pravda, že některé verze L4 (myslím že Fiasco a Pistacio) jsou v C++, ale jejich rozšíření je mizivé a kombinování C++ a assembleru není nejpřirozenější. Obecně psaní spodních vrstev knihoven, grafiky a komunikací také vychází v C celkem rozumně.
Haskell sice neumím, konceptem se mi líbí a několikrát jsem ho boostrapoval kvůli kompilaci programu Darcs. GHC dokonce ne jen využívá knihovny jazyka C, ale i veškerý překlad přes C ve výsledku provádí. Opět je tedy pro vývoj tohoto prostředí nutné, aby existovali kvalitní programátoři v jazyce C. Stejně jako pro Python, Javu atd. Přesto, že podle mého názoru patří Darcs k nejlépe promyšleným konceptům zprávy verzí, tak i částečně díky vlastnostem prostředí Haskell má někdy problémy s nároky na paměť. Proti tomu GIT, který začal opravdu jen jako bastl nad C, chodí mnoha řádově rychleji. Není to jen jazykem, je to i stylem uvažování lidí, pracujících v C. Takže každé řešení má své klady a zápory.
Pokud se jedná o operační systémy, tak si myslím, že koncep plně verifikovatelného systému CoyotOS se syscally definovanými přes IDL, který je psaný v nadstavbě BitC by byl opravdu převratný
Asi tady ovšem jen takovýmto rozborem marním čas, protože většina křiklounů nikdy nechtěla o věcech uvažovat a diskutovat, jim pouze stačí ke štěstí zhusit ostatním jejich snažení. Sami žádnou hodnotu nepřináší a kritiku tedy neriskují.
Pane ukažte mi, prosím, to C++ v NT DDK či WDF. A pak mi ukažte zdrojáky Vašich driverů pro Widows, ať vím, na jaké úrovni se s Vámi mohu bavit. Jeden zmých driverů, co lze skompilovat pro Linux, Windows KMD (to jsou pro neznalé NT) a WDM (Win98/2000/XP) model je tady. Je pravda, že existují nějaké komerční neoficiální frameworky, které dovolí psát i drivery v C++, ale DDK a Microsoft s tím nikdy nepočítal a žádnou podporu pro to nenabízí.
Přesto souhlasím, že základ jádra NT je napsán dokonale objektově a nad konceptem IRP. Je to tak čisté, že se základ od uvedení v NT nemusel měnit. Je zatím vidět, že MS cvíli dalo na lidi schopné vytvořit třeba VMS. Rozšíření o PnP a PM je však již pěkná zrůdnost. Proti Linuxu se IRP koncept jen trochu špatně používá. Vede to k duplikaci kódu a k takovým komplikacím jako je například IoSetCancelRoutine. Data může driver přijímat v IRP třemi nekompatabilními mechanizmy a je tedy nutné vědět, do jakého IRP stacku se má driver zapojit již v době vývoje. Aby toho OOP nebylo příliš, tak většina částí driverů mezi sebou komunikuje přes interní IOCTL, kterých jsou stovky a z toho mnoho nedokumentovaných.
Čekal jsem, že se na Rootu dá vést i odborná debata na úrovni. Přesto že Linux a C používám, tak se rád dozvím něco o alternativách, které klidně mohou být i technicky lepší a rád to i uznám. Sledoval jsem například i vývoj HURDu nad L4 a autorům nabízel pár vylepšení jak L4, tak správy paměti v HURDu. Nakonec dospěli k názoru, že koncepce L4 má zásadní potíže a hledají jiný základ.
Závěřem, vzhedem k prokázaným fatálním neznalostem mě již komentáře pánů "who cares" a "Biktop" nezajímají, je to jen ztráta času. Snad jejich neznalost odhalí časem i ostatní a budou jejich výkřiky ignorovat.