Transcript 01 Bevezetes - Fejlodes - Eszterházy Károly Főiskola

Hernyák Zoltán
Web: http://dragon.ektf.hu/aroan, E-Mail: [email protected]
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ó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