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é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!

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
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
WORD X_SUGAR
folytatólagosan 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ó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

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