Példa az argumentumokra és a main() visszatérési értékére:

#include <stdio.h>

int main(int argc, char *argv[])
{
   int egyik, masik;

   /* 1-gyel tobb, mint a parameterek */
   if (argc-1!=2) {
      printf("%s: ket szamot adj meg!\n", argv[0]);
      return 1;   /* nem ket parameter van: 1-es hibakod */
   }

   if (sscanf(argv[1], "%d", &egyik)!=1) {
      printf("Hibas elso parameter: %s!\n", argv[1]);
      return 2;   /* 2-es hibakod: hibas parameter */
   }
   if (sscanf(argv[2], "%d", &masik)!=1) {
      printf("Hibas masodik parameter: %s!\n", argv[2]);
      return 2;
   }

   printf("Az osszeguk: %d\n", egyik+masik);

   return 0;   /* 0-s kod: minden rendben, feladat elvegezve */
}

Windowson az elérési útban \ az elválasztó: C:\Windows\hatter.bmp, Unixon / van: /usr/bin/firefox. Az fopen() mindig elfogadja a /-t. Ha a \-hez ragaszkodunk, azt viszont \\-nek kell írni a sztring belsejében, mivel a \ önmagában a speciális karaktereket jelöli (pl. \n).

Létezik még két további megnyitás mód is:

• hozzáfűzés (a). Ilyenkor a fájlt írásra nyitjuk meg, de a meglévő tartalmát meghagyva. Az írás mutató a fájl végére mutat, vagyis a meglévő tartalomhoz hozzáadva lehet folytatni az írást.
• írás-olvasás (+). Ilyenkor írni és olvasni is lehet. Más betűkkel együtt használjuk: pl. r+ azt jelenti, hogy a fájl tartalma megmarad, de írni is lehet bele.

A szövegfájlokat a printf() és a scanf() párjával, az fprintf()-fel és az fscanf()-fel lehet kezelni. Ezeknek első paramétere a megnyitott fájl, a folytatás pedig ugyanúgy van, mint a képernyő / billentyűzet párjuknál.

A szövegfájlokat lineárisan kezeljük, nem ugrunk benne ide-oda. Bár elvileg lehetséges, de nehéz megvalósítani az adott sorra ugrást: ki kellene számolnunk a bájtban megadott pozíciót. Azt meg nem ismerjük, amíg nem olvastuk be a sorokat, mert minden sor különböző hosszúságú lehet.

Ha az előző dián látható programot lefuttatjuk Windowson és valamilyen Unix operációs rendszeren, akkor két különböző fájlt kapunk, a fent látható módon.

Ezt az adatmegjelenítést úgy nevezik, hogy „hexa(decimális) dump”. Bal oldalon a bájtok értéke hexadecimálisan, jobb oldalon pedig a hozzájuk tartozó karakterek. A vezérlőkaraktereket, vagyis az ún. nem nyomtatható karaktereket (mint az újsor vagy a tabulátor) az utóbbiban ponttal szokták helyettesíteni.

A "t"-vel, szöveges módban megnyitott fájl olvasásakor és írásakor a konverziót a C fájlkezelő függvényei automatikusan elvégzik. Vagyis Unixon pl. a \n sortörést változatlanul kiírják a fájlba, Windowson viszont a printf("\n") hatására nem egy, hanem két bájt kerül a fájlba. Viszont az automatikus konverzió miatt ezzel nekünk nem kell foglalkozni, csak annyiban, hogy "t" módban kell megnyitni a fájlt, ha szöveges formátumot szeretnénk.

A fenti apróságtól eltekintve a szövegfájlok sokkal inkább hordozhatóak, hiszen a bennük tárolt adatok nem függenek a számábrázolás módjától, amit az adott géptípus hardvere határoz meg. Ez az oka annak, hogy az utóbbi években egyre inkább terjednek a szöveg alapú formátumok:

• szöveges dokumentumok: HTML, RTF, XML (DOCX)
• adatok, adatbázisok: XML

fread(ptr, méret, db, fp), fwrite(ptr, méret, db, fp). A ptr által mutatott memóriaterület olvasása/írása az fp fájlból/fájlba. Az adat méret bájt méretű, db darabszámú elemekből áll. Visszatérési érték a sikeresen olvasott/írt elemek száma.

Itt akad egy pár újdonság. Első a void* típusú mutató (az fwrite() és az fread() első paramétere ilyen típusú). Ez a pointertípus azt jelenti, hogy nincsen meghatározva, milyen típusú elemre mutat az a pointer, hanem csak annyi, hogy valahova a memóriába mutat. Az fread() és fwrite() függvények azért várnak ilyen típusú mutatót, mivel nem foglalkoznak az általunk megadott adatok értelmével – egyszerűen csak elvégzik a fájlműveletet.

Egy valamit azért mégis tudniuk kell az adatunkról, mégpedig azt, hogy hány bájtból áll. Ezt a fordító meg tudja mondani: a sizeof(típus) kifejezés megadja azt, hogy hány bájtból áll a megadott típus. Ez kényelmes, egyrészt mivel nekünk nem kell fejben tartani, másrészt a fordító úgyis jobban tudja. Ha átvisszük egy másik géptípusra a programunkat, ott a sizeof(típus) értéke más lehet. Az fread() és fwrite() második paramétere a típus méretét adja meg, a harmadik paraméter pedig a darabszámot. Ez a megoldás tömbök kezelésére kiválóan alkalmas: előbb egy tömbelem mérete, utána a tömb elemszáma.

Az fwrite() visszatérési értéke azt mutatja, hány elemet sikerült kiírnia, az fread()-é pedig azt, hányat olvasott be. Ezek is „méret”, vagyis size_t típusúak. (A size_t típus egy egész szám, azonban a mérete (bitszáma) eltérhet az integerétől.)

Ez a program az első paraméterében kapott nevű fájlról egy másolatot készít, amelynek a nevét a második paraméterében kapja.

Az fread() a fájl végén 0-t fog adni (mert 0 bájtot olvasott be). Az fwrite() visszatérési értéke azt jelzi, hány blokkot írt ki; jelen esetben hány bájtot, mert egy blokk mérete 1 bájt (második paramétere).

Természetesen a fájlmegnyitások sikerességét, illetve az írások sikerességét is figyelni kellene, az előző diákon bemutatott módon. Még az fclose() visszatérési értékét is illene vizsgálni, mert a bezárás pillanatában is kiderülhet, hogy hiba történt a fájlba írás közben. Ezek nem fértek fel a diára.

C-ben a szabványos kimeneti és bemeneti csatornákat (adatfolyamokat, stream) is fájlként látjuk (második félévben ez elő fog még kerülni). A normál printf(…) függvény egyenértékű egy fprintf(stdout, …) hívással, a scanf(…) pedig egy fscanf(stdin, …) hívással. Az stdin neve szabványos bemenet (standard input), az stdout-é szabványos kimenet (standard output), az stderr-é pedig szabványos hibakimenet (standard error output).

A szabványos hibakimenet (stderr) a normál kimenethez hasonló a programunk számára. A kettő közötti különbség az, hogy a normál kimenetre a program által előállított eredményt, kimeneti adatot szokás írni, a hibakimenetre pedig a hibaüzeneteket. Így elkerülhető, hogy a kettő egymással keveredjen, ha a kimeneti adatokat egy fájlba szeretnénk irányítani, vagy egy másik programnak átadni.

Az előfeldolgozó további feladatai

1. Egy sorba fűzi a \ karakterrel több sorban megadott forráskódot. Vagyis ez a kettő egyenértékű:

   printf("\
   hello\
   hello");

   printf("hellohello");
   
   

2. Összefűzi a közvetlenül egymás mellett álló sztring konstansokat: "Hello" "vilag" = "Hellovilag".
3. Kicseréli az ún. hármas karaktereket (trigraph) a megfelelő párjukra. A C megengedi, hogy egyes írásjeleket, pl. [], <> stb. más karakterekkel helyettesítsünk. Ennek célja az, hogy lehessen olyan billentyűzeten is C programot írni, amelyeken ezek nincsenek – látszik, hogy ez egy nagyon régi, mára elavult lehetősége a nyelvnek. Ez egy helyes C program:

   ??=include <stdio.h>
   
   int main(int argc, char *argv??(??))
   ??<
      printf("hello world\n");
   ??>

   A csere sztringeken és kommenteken belül is megtörténik. Egy sztringben lévő egymás utáni két ?? karakter hatására ez aktiválódhat, azért fontos tudni róluk. Manapság kódot így nem szokás írni, sőt egyes fordítóknak külön jelezni kell, ha kérjük ezeket a helyettesítéseket.

A C maga is tartalmaz ilyen konstansokat. Pl. a beépített típusok értékkészletét mutató makrók a limits.h-ban.

#pragma – nem szabványos kiterjesztések

A fordítók saját, nem szabványos kiterjesztései. Ha egy fordító nem érti a #pragma sort, figyelmen kívül hagyja. Pl.

#pragma omp parallel for schedule(dynamic)  /* OpenMP */
for (y=0; y<magassag; y++) {
    …

OpenMP: az ezt ismerő fordítóknak megadhatjuk, hogy egy ciklus iterációit szétossza a gépben lévő processzorok (magok) között.

Mivel semelyik #pragma nem lehet szabványos (éppen az a célja, hogy jelezze a fordítónak, nem szabványos dolgot írunk be), ezért a #pragma once használata tilos. A fejlécfájlok többszöri feldolgozása ellen az #ifndef+#define technikát kell használni, amelyet minden fordító felismer.

Ha a projekt egyetlen, nagy forrásállományban lenne megírva:

• akkor áttekinthetetlen lenne,
• a szerkesztő programok nehezen/lassan kezelnék,
• nehézkes lenne többen egyszerre dolgozni rajta,
• egy-egy újrafordítás akár órákat vehetne igénybe.

Ha szerkezeti egységekre bontjuk a programot:

• ezek önállóan fordíthatóak, a program ezek összeépítéséből lesz,
• egy csapat különböző tagjai egymástól függetlenül dolgozhatnak,
• az egyedi fordítások gyorsan lezajlanak.

Ez az egyedül fejlesztett programoknál is nagyon hasznos: az egyes modulok újra felhasználhatóak más projektekben. Érdemes a funkcionális egységeket általános módon megírni, hogy minél könnyebben fel lehessen használni őket más feladatok megoldásában.

A terveink a következők. A megrajzolt függvényekhez egy csomó szakasz tartozik. Ezek különböző színűek is lehetnek. Eltároljuk őket egy tömbben. De nem csak ezek a szakaszok tartoznak a képhez, hanem annak vannak egyéb tulajdonságai is: tudni kell, mekkora (kx, ky), hol van rajta az origó (ox, oy) és hogy mekkora a nagyítása (nx, ny). Az utóbbi azt jelenti, hogy a monitoron hány képpont jelenti a matematikai koordinátarendszerben az egységet. Ha mindezek megvannak, akkor egy függvény kirajzolható.

Ezek alapján a rajz struktúra tartalmaz egy szakaszokból álló tömböt. Az egyes rajzokon eltérő számú szakasz lehet, így a darabszámot is felvesszük emellé. Meg kell becsülnünk azt is, hány szakaszból állhat egy rajz; itt azt mondtuk, 1000-nél több ez nem lehet. (Későbbi előadásokon majd lesz szó arról, hogy az ilyen előnytelen, ex-has becslések helyett milyen megoldásokat tudunk alkalmazni.)

A nyíl operátort azért találták ki, mert a . mezőkiválasztó operátornak magasabb a precedenciája, mint a * dereferáló operátornak. Ha ennyit írnánk: *pr.kx, akkor azt a . magasabb precedenciája miatt *(pr.kx)-ként próbálná meg értelmezni a fordító, ami viszont nyilván nem lehetséges, hiszen pr nem struktúra, hanem pointer, amelynek nincsenek mezői. Ha nem lenne a nyíl operátor, akkor minden ilyen hozzáférést zárójelezni kellene, mint ahogyan az fent a buborékban is látszik.

Struktúrákra mutató pointerek esetén mindig ezt használjuk, mert egyszerűbb, olvashatóbb kódot kapunk, mintha zárójelezni kellene. (Ahogyan az indexelő operátor esetén: tomb[i] helyett sem írunk *(tomb+i)-t, mert nehézkesebb, bonyolultabb, és semmivel nem jobb, mint az indexelő operátoros forma.)

Tervezzük meg az algoritmusokat! Legfontosabb a függvény kirajzolása – ezzel foglalkozzunk.

A monitoron és a képeken más koordinátarendszert szokás használni (origó bal felső sarokban, x jobbra, y lefelé), mint a matematikában (origó középen, x jobbra, y felfelé). A rajzaink nagyítása is változhat. Ezért praktikus függvényeket írni, amelyek ezen koordinátarendszerek között a transzformációt elvégzik, mert így bármikor át tudunk térni a képbeli koordinátákról a matematikai koordinátákra és fordítva. Ezek a függvények a kep2mat() és a mat2kep().

Ezek segítségével már könnyű megvalósítani a függvény ábrázolását. A rajzolást, ha a kép koordinátarendszerében végezzük, akkor biztosak lehetünk abban, hogy nem lesz túl cakkos sem a függvény (mint az előző képen), de nem is számoljuk ki feleslegesen sok pontban (olyan sűrűn, hogy már nem is látszik a különbség – ez csak foglalná feleslegesen a memóriát, és megtelne a szakaszok tömbje). Ezért a kép koordinátái szerint haladunk egyesével; előbb átalakítva a képkoordinátarendszerbeli x-et matematikai koordinátává, ami a függvénybe behelyettesíthető. Az így kapott matematikai y koordinátát utána képbeli y koordinátává alakítva megkapjuk az SVG fájlba írandó szakasz koordinátáit.

Pointer, ami egy függvényre mutat. Paramétere: egy double, visszatérési értéke is egy double.

double (*pfv)(double);

A fenti negyzet() függvénynek is ilyen az aláírása, és a math.h sin() függvényének is. Bármelyik egyéb, ugyanilyen aláírással rendelkező – egy double paraméterű, double visszatérési értékű – függvényt képes így ábrázolni a rajzoló!

A függvényekre mutató pointerekről egy későbbi előadáson lesz szó. Most csak említésképp szerepelnek; a NZH-ban még nem lesz ilyen.

A programot két modulra lehet bontani. Az első a fő programmodul. Ez tartalmazza a main() függvényt, a menu() függvényt, és az ábrázolandó parabolát kiszámoló függvényt is. A másik modul a függvények megjelenítését tartalmazó programrészekből áll össze. Érezhető, hogy ez egy külön egység, amely önmagában is megállja a helyét. Lehetne egy teljesen másik programot is írni, és abban ugyanezt az ábrázolót használni.

Az ábrázoló függvényeit ezen belül tovább lehet bontani két csoportra. Azok a függvények, amelyek az ábrázoló modul használója számára is fontosak, például a rajz_inicializal() és a fuggveny_rajzol(). Ugyanebbe a csoportba tartozik a függvények mellett a Rajz nevű típus, hiszen ezt is ismernie kell annak, aki használni szeretné. Definiálnia kell tudni Rajz típusú változót! A másik csoportba olyan függvények tartoznak, amelyek a használó számára nem lényegesek, sőt jobb ha nem is kell foglalkoznia velük. Ezek például a koordinátarendszer-transzformációt végző kep2mat() és mat2kep() függvények.

Vagyis fogjuk az összes olyan típust és függvényt, amelyeket láthatóvá szeretnénk tenni a többi modul számára, és készítünk belőlük egy fuggveny.h nevű fejlécfájlt a fuggveny.c modul mellé.

Mi kerül a forrásfájlba (.c), és mi kerül a fejlécfájlba (.h)? Ez egyszerű: a kódfájlokba (.c) mennek a függvények definíciói, a fejlécfájlokba mennek a függvények deklarációi. Persze csak azok, amelyeknek máshonnan is látszaniuk kell, másik modulból. A statikus függvényeket, amelyek csak az adott modulból látszanak, nincsen értelme (sőt: hiba!) szerepeltetni a fejlécfájlban, hiszen azok a statikus jellegük miatt amúgy sem érhetők el máshonnan. Ugyancsak a fejlécfájlokba mennek a kívülről is használható típusok definíciói.

Ezt a fejlécfájlt a többi modul, amely szeretné használni a függvényrajzoló modul szolgáltatásait, beilleszti a saját forráskódjába az #include "fuggveny.h" sorral. Így a fordító érteni fogja, mi az, hogy Rajz, és azt is fogja tudni, hogy létezik a rajz_inicializal() függvény, ismeri a paramétereinek típusait és így tovább. Le tudja fordítani a kódot!

Fontos, hogy a fejlécfájlt nem csak a többi modulnak kell beillesztenie, hanem annak a modulnak is, amelyhez tartozik. Vagyis jelen esetben a fuggveny.c-nek is include-olnia kell a fuggveny.h-t! Ennek oka kettős: egyrészt a függvényrajzoló kódjának is ismernie kell a hozzá tartozó típusokat (Szakasz, Rajz), másrészt pedig így biztosítható az, hogy a modul forráskódjában nincsenek véletlenül hibásan megadva a függvények paraméterei. Ha a forrásfájlban más fejléccel definiálunk egy függvényt, mint a fejlécfájlban, akkor az a projekt fordításakor hibához vezet. Ha beillesztjük minden modulba a saját fejlécfájlját is, akkor ezeket a hibákat a fordító megtalálja!

Az #ifdef és #ifndef direktívákkal ellenőrizni tudjuk, hogy definiálva van-e egy makró, és attól függően egy programrészt teljesen kihagyhatunk a fordításból. Jelen esetben ezt arra használjuk, hogy biztosítsuk azt, a függvények ne legyenek többször deklarálva. Összetett projektek esetén ugyanis a fejléc fájlok általában egymást is betöltik (include). A fenti preprocesszor direktíva úgy működik, hogy az első betöltéskor még beilleszti a kódot, mivel a FUGGVENY_H_BEILLESZTVE makró ilyenkor még nincs definiálva: #ifndef. De egyből definiálja is, vagyis másodjára már az egész kódrészlet kimarad.

A kész programunk most három lépésből állítható elő:

1. Le kell fordítani a függvény modult. Ebből egy tárgykód fájl keletkezik.
2. Le kell fordítani a főprogram modult is. Ebből is egy tárgykód lesz.
3. Végül pedig a két tárgykódot össze kell szerkeszteni.

Az összeszerkesztéskor (linking, „linkelés”) nem csak az általunk írt függvényeinket, hanem a szabványos C könyvtári függvényeket (printf(), sin() stb.) is megkeresi a linker.

A három műveletet az itt látható parancsok begépelésével lehet elvégezni Linux rendszeren. Windowson is hasonlóképpen működik. A fordítási és szerkesztési lépéseket egyébként az integrált fejlesztőkörnyezetek automatikusan elvégzik, azt ritkán kell parancssorból, kézzel végeznünk: a laboron használt Code::Blocksban is csak egy kattintás, és indul is a lefordított programunk.

Ugyancsak automatikusan végzik a fejlesztőkörnyezetek a függőségek feltérképezését. Figyeljük meg az ábrán: az egyes fájlok módosítása esetén nem kell mindegyik műveletet újra elvégezni. Például ha a main.c fájl tartalmát szerkesztjük, akkor nincsen szükség a fuggveny.c újbóli fordítására, hiszen azon lépés által keletkező fuggveny.o fájl tartalma nem függ a main.c tartalmától. Szükség van viszont a main.c fordítása után az újbóli linkelésre is, hiszen a megújult main.o-tól függ a végleges programfájl, a fuggveny tartalma. Így végeredményben egy fordítást tudunk megspórolni ebben az esetben.

Nagyobb projekteknek ennél sokkal bonyolultabb függőségi gráfjuk van. A függőségek figyelembe vételével könnyen meghatározható az, hogy egy adott fájl módosítása esetén mely fordítási, linkelési lépéseket lehet elhagyni. Minél kisebb részekre, fájlokra van bontva a projekt, annál kisebbek lehetnek az újból elvégzendő lépések, hiszen annál több fájl marad változatlan egy kisebb módosítás esetén.

A függvényen belüli statikus változót is értelmezhetjük úgy, mint az előbbit: ez egy olyan globális változó, amely csak a függvényen belül látszik. (Ennek ellenére a függvények statikus változóit nem szokták globálisnak nevezni.)

Ezt a funkciót nagyon ritkán használjuk. Nem is igazán ajánlott ilyen függvényeket írni, mert az olvashatóságot rontja, ha egy függvény visszatérési értéke nem kizárólag a bemeneti paraméterek értékétől függ. Sok beépített, könyvtári függvény használja azonban, ezért fontos, hogy ismerjük és tudjuk, hogy mi történik a háttérben. Ilyen például a strtok(), amely arra használható, hogy egy szöveget bizonyos határoló karakterek mentén feladaraboljunk. Például a "Szia, ez itt egy proba. Futtass le!" szöveget úgy darabolhatjuk fel szavakra, hogy határoló karakterként megadjuk a következő karaktereket: ' ', ',', '.', '!'.

#include <stdio.h>
#include <string.h>

int main() {
  char str[]="Szia, ez itt egy proba. Futtass le!";
  char *pch;

  printf("Az eredeti szoveg: %s\n",str);

  pch = strtok(str," ,.!");
  while (pch != NULL) {
    printf("%s\n",pch);
    pch = strtok(NULL, " ,.!");
  }

  return 0;
}

Látható, hogy az strtok függvény első hívásakor megadjuk a feldolgozandó sztringet, de a későbbiekben már NULL pointerrel hívjuk. Honnan tudja hát, hogy milyen szövegen dolgozzon? A másik talány pedig az, hogy hogyan tudja megjegyezni, hogy hol tart a szövegben, hiszen minden híváskor a soron következő szóval tér vissza.

Mindkét kérdésre a static változó a megoldás: amikor egy nem NULL pointerrel hívjuk meg, akkor egy static char * típusú változó értékében elmenti ezt a címet. Elkezd a sztringgel dolgozni, visszatér az első szóval és a static változó értékét beállítja a soron következő szó elejére. A következő hívásnál NULL pointerel hívjuk, így tudja, hogy folytatnia kell egy korábbi sztringet. A cím pedig, amivel dolgoznia kell, el van tárolva a static változóban.

Az assert.h-ban definiált makró megszakítja a program futását, és hibaüzenetet ír ki, ha a paraméterként kapott kifejezés hamisra értékelődik ki.

Ha definiálva van az NDEBUG makró, akkor üres utasításra cserélődik – vagyis a program végleges változatát már nem lassítják az ellenőrzések.