Hernyk Zoltn Web http dragon ektf huaroan EMail

Hernyák Zoltán Web: http: //dragon. ektf. hu/aroan, E-Mail: aroan@aries. ektf. hu Magasszintű Programozási Nyelvek I. Eszterházy Károly Főiskola Számítástudományi tsz http: //aries. ektf. hu 1

A jó programozási nyelv: Ø Könnyen elsajátítható alapelvek Ø Áttekinthető leírás Ø Könnyen módosítható kód Ø Nehéz hibát elkövetni benne Ø Könnyen dokumentálható 2

1. gen. : Gépi kódú programozási nyelv Ø Egyetlen „jó” jellemzővel sem bír Ø A kód számok sorozata Ø Egy „szám” egy utasítás Ø Relatíve sok utasítás Ø Nincs változónév Ø Nincs eljárásnév Ø Nincs ciklus Ø Memóriacímekre hivatkozás számkóddal 3

Példa: Mem. cím Gépi kódú utasítás Assembly utasítás 4

Egyéb problémák: Ø A számkódokat a memóriába kell juttatni Ø Ha másik memóriaterületre tesszük, az gondot okozhat Ø A gépi kód processzorfüggő 5

Előnye: Ø Maximális futási sebesség Ø Elvileg minimális memóriamennyiségfelhasználás Ø A mikroprocesszor és az egyéb hardware elemek képességeinek maximális kihasználhatósága „Amit nem lehet megírni gépi kódban, azt nem lehet megírni!” 6

2. gen. : Assembly programozási nyelv Ø Néhány „jó” jellemzővel bír Ø Az utasításokat betűkombinációk jelölik (mnemonikok) Ø Pl: „MOV” == „move” == „mozgatás” Ø Egy ilyen mnemonik egy gépi kódú utasításnak felel meg Ø Sokkal könnyebb megjegyezni a nyelvet 7

Ø Sokkal nehezebb hibázni Ø Az elgépelés észrevehető („MUV” utasítás nincs: ) Ø A program ezen formája olvashatóbb Ø Könnyebben módosítható Ø Könnyebben megérhető 8

Példa: Mem. cím Gépi kódú utasítás Assembly utasítás 9

Új fogalmak: Ø Forráskód (source code): a program szöveges formájú leírása Ø Tárgykód (object code): a program gépi kódra fordított formája Ø Fordítóprogram (compiler): amely a transzformációt elvégzi 10

Új fogalmak: Ø Fordítás (compiling): a folyamat, melynek során a fordító program a forráskódból előállítja a tárgykódot Ø De-compiler: a tárgykódból visszaállítja a forráskódot (veszteséges) 11

Elkezdődött a fordítóprogram intelligenciájának fejlődése! 12

Változó fogalmának primitív változata: ØMemóriacímnek azonosító adományozása ØA forráskódban ezen azonosítók használhatók ØNöveli az olvashatóságot ØCsak egy helyen kellett módosítani a forráskódot ha a memóriaterület címe változott X_SUGAR Y_SUGAR 5420 5422 add ax, [X_SUGAR] 13

Ami hiányzik: ØNincs típusfogalom ØAz azonosító inkább „konstans” szerepét töltötte be ØA memóriacímek meghatározása a programozó feladata ØA memóriaterületek átlapolhatóak voltak, illetve „lyukak” lehettek közöttük 14

Fejlődés: ØAz azonosítóhoz primitív „típusnév” csatlakozik ØEz egyetlen szerepet töltött be: meghatározta a memóriaigényt ØÍgy lehetőség nyílt az azonosítókhoz tartozó memóriacímek automatikus kiosztásához, egy kezdőcímhez (base address) viszonyítva folytatólagosan WORD X_SUGAR WORD Y_SUGAR add ax, [X_SUGAR] 15

Még mindig hiányzik: ØA változó helyes kezelésének ellenőrzése ØPl: egy négybájtos területet lehetett kétbájtosként, egybájtosként is kezelni ØNincs különbség a „bool”, „char”, „signed short”, „signed long” között, mindegyik 1 byte memóriaigény ØÉlettartam ØHatáskör 16

Programozási stílus fejlődése: ØCsak ugró utasítás létezett ØAz ugrás kiszámítása relatív címekkel történik (pl. „ugorj vissza 16 byte-nyit, és folytasd onnan a programot”) ØVan eljáráshívás. Megvalósítása ugorj … memóriacímre … térj vissza 17

Programozási stílus fejlődése: ØAz ugró utasítások pontos helyét azonosítókkal jelölték meg: Ciklus_ujra: push ax mov ax, cx jnz @Ciklus_ujra 18

Programozási stílus fejlődése: ØA jól megválasztott azonosítónevek szintén növelik a forráskód olvashatóságát ØNehéz elrontani az ugrás helyének azonosítását (elgépelés valószínűleg hibás) ØAz eljárások belépési pontját is azonosítónév jelöli (ez már majdnem ELJÁRÁSNÉV) call @kiiras 19

Több modulból álló projekt (1): ØLehetőség nyílik a forráskódok egyesítésére (#include) ØA program „hosszú” kódját szét lehet tördelni apróbb, e miatt jobban kezelhető forráskódrészekre ØA forráskód-darabokat a fordítóprogram egyesítette 20

Több modulból álló projekt (2): ØA fordítás gyorsítása érdekében a forráskódrészek külön kerülnek lefordításra ØAz apró tárgykódokat egyesíteni kell, és a kereszthivatkozások helyességét ellenőrizni Szerkesztő (linker) program Szerkesztés (linking) fázis A futtatható program előállítása egyre több, jól elkülöníthető fázisra bontható fel 21

Még mindig hiányzik: ØNincs tisztán eljárás, az eljárás „törzsébe” is közvetlenül be lehet ugorni ØEgyetlen „eljárás” belsejében is tetszőleges módon lehet ugrálni előre-hátra ØAz assembly nyelv is processzorfüggő 22

Még mindig hiányzik: ØNincs rögzített módszer Øaz eljárások paraméterátadására (több módszer is létezik) ØÉrtékek (pl hibakód) visszaadására 23

Elkezdődött egy folyamat: általános célú rutinok megírásának igénye. Ez rohamosan csökkentette a fejlesztési sebességet! ØNem kell megírni ØNem kell tesztelni „Amit nem lehet megírni assemblyben, azt meg lehet írni gépi kódban. Amit nem lehet megírni gépi kódban, azt nem lehet megírni!” 24

3. gen: Eljárásorientált nyelvek Elvi, szemléletbeli váltás történt ! ØRögzített paraméterátadási technikák ØÉrték szerinti ØCím szerinti ØRögzített érték-visszaadási technika (függvények) ØA formális és aktuális paraméterlista egyezőségének ellenőrzése! 25

Típusok: ØMegjelentek a nyelvi alaptípusok (bool, char, int, float, …) ØMegjelentek az egyszerűbben megvalósítható összetett típusok (tömb, rekord) ØSaját típusok definiálhatóak ØTípusátnevezés (név változtatása) ØMeglévő típusok szűkítése (pl. résztartomány-típusok) 26

Típusok: ØA változók típushoz rendelése (deklaráció) ØKifejezések írhatósága, típushelyességének ellenőrzése ØÉrtékadás típushelyességének ellenőrzése ØParaméterek kezelése közbeni típushelyesség ellenőrzése 27

Programvezérlési szerkezetek: ØTörténelmi okokból megmaradt a „goto” ØA három alapvető programvezérlési szerkezet ØSzekvencia ØSzelekció ØIteráció ØUtasításblokkok kialakíthatósága 28

További előnyök: ØNem processzorfüggő ØA fordítás menete lehetséges: ØElőször a 3. generációs forráskód átfordítása assembly forráskódra ØAssembly nyelvre már létezik fordítóprogram ØMa már közvetlenül a gépi kód generálása a jellemzőbb 29

Korlátok: ØSaját típus fejlesztése igazából nem lehetséges. Nincs lehetőség olyan „típus” kifejlesztésére, mely a nyelvbe olyan szinten beépül, mint a gyári típusok ØNincs lehetőség új operátorok fejlesztésére, a meglévőek jelentésének finomítására, a precedenciaszint megváltoztatására, stb… ØA nyelv kevéssé fejleszthető 30

3. gen: Objektum-orientált nyelvek Elvi, szemléletbeli váltás történt ! ØAnnyi a hasonlóság a procedurális nyelvek között, hogy nem tekintik külön generációnak ØA fordítóprogram intelligenciája, hibakiszúró képessége tovább fokozható ØSaját típusok fejlesztése majdhogynem „korlátok nélkül” 31

4. gen: Speciális nyelvek ØSpeciális feladatkörre orientálódott (pl adatbáziskezelés, grafika, matematika, …) ØNagyon gyorsan elsajátítható, beszélt nyelvre (angol) emlékeztető szintaxis ØNem kifejezetten szakemberek számára tervezett 32

5. gen: Mesterséges Intelligencia ØNem készült el (készítése folyamatban) ØSpeciális processzor érti meg csak 33

Programozási nyelvek csoportosítása Ø 1. Imperatív (procedurális) nyelvek Ø 2. Applikatív (funkcionális) nyelvek Ø 3. Szabály alapú (logikai) nyelvek Ø 4. Objektumorientált nyelvek 34

Imperatív nyelvek ØÉrtékadó utasításokat használ ( a : = b+c; ) ØEzeket végrehajtva közelít a megoldáshoz ØAz elágazások és ciklusok segítik, hogy melyik értékadó utasítást, hányszor kell végrehajtani ØErősen épít a változó fogalmára 35

Funkcionális nyelvek ØNincsenek benne változók, és e miatt értékadó utasítás ØFüggvények vannak benne, amelyeket ki kell értékelni ØMINDEN függvény benne, még az is, ami nem látszik annak ØA program egy nagy, bonyolult, összetett fv kiértékelését jelenti 36

Logikai nyelvek ØFormális logika és halmazelmélet szabályaira épül ØTényeket tárol (tudásbázis) ØKérdéseket lehet megfogalmazni benne ØA kérdésekre a választ a beépített tények alapján a nyelv által használt módszerint megkeresi a választ 37

Objektum-orientált nyelvek ØEgymással kölcsönhatásban álló objektumok összessége ØMinden objektumnak van interface, amely definiálja, hogy mit lehet az adott objektummal végezni, végeztetni ØAz objektumok egymással egymás interface-in keresztül kommunikálnak 38

Objektum-orientált nyelvek ØEgy, az interface-beli tevékenység meghívását üzenet-nek hívjuk (‘azt üzenjük neked, hogy mentsd ki az adataidat’) ØEgy tevékenységet általában többféle paraméterezéssel is el lehet érni (overloading) ØAz objektumok hordozzák saját állapotukat (változókban (mezőkben)) 39

Objektum-orientált nyelvek ØHa egy műveletet az adott objektum visszautasít, szabványos módon jelzi a hibát a hívónak (kivételkezelés) Østb… 40

Objektum-orientált nyelvek ØAz OOP nyelvek is imperatívak ØAz alap szintaxis (értékadás, elágazás, ciklus, …) leírására nem találnak ki új nyelvet, hanem egy már meglévő nyelv szintaxisát használják fel: C -> C++ 41

Objektum-orientált nyelvek ØHagyományos nyelv: nem ismeri az OOP fogalmakat sem ØOOP támogató nyelv: a nyelv ismeri az OOP fogalmakat, de lehet benne hagyományos programokat is fejleszteni (vegyesen) ØOOP nyelv: csak OOP szemléleten keresztül lehet benne fejleszteni 42