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ň