Hernyák Zoltán Magasszintű Programozási Nyelvek I.

Hernyák Zoltán Magasszintű Programozási Nyelvek I.
A programozási nyelvek fejlődése Hernyák Zoltán Web: Magasszintű Programozási Nyelvek I. Eszterházy Károly Főiskola Számítástudományi tsz 1

A programozási nyelvek fejlődése
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

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

„Amit nem lehet megírni gépi kódban,
A programozási nyelvek fejlődése Előnye: Maximális futási sebesség Elvileg minimális memóriamennyiség-felhaszná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!
A programozási nyelvek fejlődése 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 5420 Y_SUGAR 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

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 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) 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ód-ré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 A Neumann elvű gépek memóriarekeszekben, és bennük tárolt értékekben gondolkodnak. De megjegyeznénk, hogy más ettől eltérő elvű programozási nyelvek is vannak, amelyek távolabbi absztrakciós szinten közelítik meg a probléma leírását, és megoldását. 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ódszer szerint 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

Hernyák Zoltán Magasszintű Programozási Nyelvek I.

Hasonló előadás

Az előadások a következő témára: "Hernyák Zoltán Magasszintű Programozási Nyelvek I."— Előadás másolata:

Hasonló előadás

Projectumról

Visszajelzés

Bejelentkezés

A társadalmi hálózaton keresztül belépni:

Hernyák Zoltán Magasszintű Programozási Nyelvek I.

Hasonló előadás

Az előadások a következő témára: "Hernyák Zoltán Magasszintű Programozási Nyelvek I."— Előadás másolata:

Hasonló előadás

Projectumról

Visszajelzés