C++ kontra Pascal (HiPP kontra ReDox)
Další článek bude zaměřen na porovnání dvou nejpoužívanějších
programovacích jazyků. Ano uhodli jste, jde o C++ a Pascal. Dnes se
zaměříme na I/O (vstupně/výstupní) funkce. Pascal je jimi bohatě
vybaven. Nepočítáme-li fce ("logicky" to bývají procedury) na
načítání jednoho znaku, má Pascal celkem 6 funkcí. Z toho jsou dva
páry téměř totožné (Write + WriteLn, Read + ReadLn), z čehož málokdo
ví, jak se dá použít procedura Read. Nebudu se o nich už více
rozepisovat, protože jsou notoricky známé (nejen notorikům). Další
méně známé, ale ne méně kvalitní jsou BlockRead a BlockWrite.
Načítají (zapisují) ze (do) souboru do nějaké neidentifikované
proměnné (Paskalisti nemaj rádi pointry,tak dělaj takovýhle prasárny)
Ale jinak tu už nestojí nic za zmínku. Stojí-li zmíním se o nich
v druhé části věnované C++..
C++ ovládá 3 typy přístupu k souborům.
1) Přes pointer na strukturu FILE (v knihovně STDIO, CONIO).
Procedurám WriteLn a Write odpovídá fprintf (printf, cprintf,
sprintf...) k ReadLn tu máme fscanf a jeho mutace. Jak vidíte je jich
poněkud více. Jsou mezi nima obecné fce, ale i fce na speciální
situace (na jejich použití se koukněte do helpu). A nejen to, je tu
takzvaný formátovací řetězec, který určuje, jako co bude určitá
hodnota načtena či vypsána. Ekvivalenty procedur BlockRead/BockWrite
tu jsou fce fread fwrite. V Pascalu musíte předem určit typ
načítaných proměnných. Např. file of integer. V C++ jen při otvírání
souboru oznámíte, má-li se chovat jako textový nebo binární. Je-li
jako textový, chová se jako Pascalský soubor typu Text. Je-li však
otevřen jako binární, načítá byty podle formátovacího řetězce.
Napíšete-li tedy fscanf(f,"%c%i",b,i) načte ze souboru f do proměné
b jeden byte a do proměné i 2 byty.
ReDox - Genialitou Write(Ln) a Read(Ln) si Pascal zajistil mnoho
příznivců. Jejich výhody jsou samozřejmě oproti C++
neporovnatelné, i když se jedná více méně o zvyk, ale já
odmítám zdvojovat lomítka, z čehož plyne, že Pascal v
tomto směru vede. A teď bacha! Pascalisti narozdíl od
céčkařů žádné prasarny nedělají, jedná se jen o netypovou
proměnnou, což je jeden z dalších geniálních nápadů
Pascalu a ne prasárna. Většina céčkařů si totiž
neuvědomuje, že to, čemu oni říkají pointer,je v podstatě
úplně zbytečná záležitost, jelikož Pascal se v místech,
kde oni složitě hvězdičkují, postará o vše sám. V Pascalu
je totiž přehledně rozlišeno to, co je v datasegmentu a
to, co se alokuje až při průběhu programu a to považuji
za další plus k přehlednosti programu, kde Céčko výrazně
pokulhává. A ještě jedna věc, to,že si v C musíte zadávat
jakého typu se bude proměnná načítat/vypisovat přímo v
řetězci (jde zase jen o zvyk), ale co je podstatné, že
pokud mám strukturu například A=Record X:String;
Y:Longint; Z:Real end; a chci s ní v Pascalu pracovat v
oblasti I/O, je C, alespoň podle mého názoru, v koncích,
Pascal však zvládá vše jako obvykle elegantně.
Nadefinujeme soubor typy F:File of A a v programu
jednoduše Read(F,A)/Write(F,A), ale v C ? Tak snad jen
postupně po jednotlivývh prvcích, ale to, jak jistě
uznáte, je dosti těžkopádné, takže Pascal zase vede.
2) Přes tzv. streamy v knihovně IO.H zde jsou fce. podobné hlavně
BlockReadu a BlockWritu, tzn. jsou určeny hlavně pro přenos větších
množství dat.
3) Nejlepší a Packalistům nejméně známé fce pro práci se soubory
jsou v knihovně FSTREAM.H. Tyto fce jsou objektové, takže si je
můžete upravit k obrazu svému. Ale myslím si, že to není potřeba.
Asi nejpoužívanějším objektem z této hnihovny je fstream. Jde
o objekt určený pro práci se soubory. Soubor se otevírá metodou open,
to je úplně normální. Ale jeho další metody jsou nádherné. Je zde
použito přetěžování fcí. To znamená, že když fci zavoláme s jedním
parametrem, může se chovat, jako když ji zavoláme s parametrem jiného
typu. Zde se dost používá operátor >> respektive <<. Napíšu-li tedy
cout<<"ahoj "<<s; pošle na obrazovku (cout = console out) řetězec
ahoj a obsah proměnné s. Je-li s int tak tam pošle integer, je-li to
ukazatel na char pošle tam řetězec atp. Operátor >> funguje opačně:
čte ze streamu do proměnné. Ale to není nic zvláštního. Některé
objekty této knihovny mají vlastní buffer, takže nemusejí pro každý
byte přistupovat na disk. To dost urychlí práci programu, když musíte
vyhodnocovat zvlášť (šifrování,čtení grafických souborů atp.).
Poznámky k PIŽIho článku Asembler pro blbé
Článek je to dobrej, líbil se mi, ale mám tu jednu poznámku.
Dal jsem totiž na radu uvedenou v článku a opravdu jsem provedl
měření. Napsal jsem programy v C++ a Pascalu, o kterých si myslim, že
odpovídají zdrojáku v asembleru. Pro jistotu jsem dal počet
kopírování na 10000. A výsledky mně celkem překvapily.
Měření jsem prováděl na 486/25, kompiloval jsem TASMem z BC 3.1,
BC 3.1, a TP 7.0. Měřil jsem Turbo profilerem 2.2. A teď vám už ukážu
jak měření dopadlo.
+---------+----------+------------+----------+
|Program | Čas/s | Čas/% | Velikost|
+---------+----------+------------+----------+
|Asembler | 29.504 | 100.00% | 556 |
|C++ | 30.647 | 103.87% | 7856 |
|Pascal | 61.217 | 207.48% | 1728 |
+---------+----------+------------+----------+
Čas je průměr čtyř měření
Jak je vidět C++ se rychlostí, narozdíl od Pascalu, slušně drží
Asembleru, ale ta velikost. Je to tím, že BC++ 3.0 přikompilovává
celou knihovnu.
HIPP
ReDox - Tento příklad rozhodně nevypovídá o kvalitě kompilátoru a
už rozhodně ne o kvaltě jazyka. To, že C++ vypadá jako
sofistikovaný optimalizátor, je v tomto příadě aboslutní
blbost, musíme si uvědomit, že použitá instrukce MovSD,
která celý tento zázrak vykonala,je 32-bitová a jak možná
všichni dobře víte, tak Pascal generuje zásadně 286 kód a
to jen za předpokladu, že ho k tomu donutíte. Z toho
plyne, že Pascal vygeneruje místo mov cx,16000 a rep
movsd, kód mov cx,32000 a rep movsw, z čehož je krásně
vidět, že se jedná v podstatě o 2x pomalejší operaci.
Takže HiPP se vám zde snaží komentovat závody dvou
motocyklů značky Assembler 500 a C++ 500 s jedním značky
Pascal 250, což je opravdu nehorázné a podlé k našemu
milovanému Placalu 7.0, který byl ve své době absolutní
špičkou, ale bohužel nových verzí jsme se dosud nedočkali
a asi ani nedočkáme, takže o mrtvích jen v dobrém,
protože Pascal je nejlepší jazyk všch dob a to myslím
zcela vážně!
výheň