|
Az informatikában az adattípus (gyakran röviden típus) az értékek egy halmazához rendelt név vagy címke és ezen halmaz értékein végrehajtható néhány művelet. A programnyelvek explicit vagy implicit módon támogatják az adattípusok használatát, amelyeket a nyelv statikusan vagy dinamikusan ellenőrzött típus kényszerítés, ezzel biztosítja, hogy érvényes, helyes programokat hozzon létre az adott nyelv.
AlapokA jelentés nélküli bitek csoportjához szemantikai jelentéssel bíró típus hozzárendelése a célja a típus meghatározásnak. Típust gyakran vagy a memória területhez vagy egy objektumhoz illetve változóhoz rendelnek, önmagában a számítógép hardver nem tesz különbséget memóriacím, utasítás kód, karakter, integer vagy lebegőpontos szám között. A típusok arról adnak információt a programnak és a programozónak, hogyan kell kezelni az adott bitek csoportját. A típusok használata leginkább a következő területeken biztosít előnyt:
Típus ellenőrzésAz eljárás, ami vagy fordítási időben (statikus ellenőrzés) vagy végrehajtási időben (dinamikus ellenőrzés) ellenőrzi típuskényszerítés szabályait, és szükség esetén végrehajtja a előírt művelet(ek)et. A statikus ellenőrzés elsődlegesen a fordítóprogram feladata. Ha a nyelv kikényszeríti a típushoz tartózó szabályok végrehajtását (ez általában a típuskonverziók végrehajtását jelenti, lehetőleg információ vesztés nélkül), akkor a nyelv erősen típusos, ellenkező esetben gyengén típusos. Statikus és dinamikus típusokA dinamikus típus hozzárendelés és ellenőrzés szinte minden esetben a futásidőben történik, mivel az egyes változókhoz ekkor rendelődik hozzá az aktuális típusuk (program végrehajtási ideje). A statikus típus rendszer dinamikus használata általában szükségessé teszi egy olyan rendszer kidolgozást, ami a futási időben képes arra, hogy a kövesse az időben esetleg változó típushozzárendelések változásait. Ez az igény egyrészt triviálisnak, de ugyanakkor a helyes működés biztosítása miatt nehézkes is tűnik. C, C++, Java, ML, és a Haskell statikus típus kezelést és ellenőrzést használják, míg a Objective-C, Scheme, Lisp, Smalltalk, Perl, PHP, Visual Basic, Ruby, és a Python dinamikus kezelést és típusellenőrzés valósítják meg. A trend azt mutatja, hogy a típus kezelést a fordított nyelvekben használják. Kacsa típusosság egy humoros meghatározása az úgynevezett scripting nyelveknél használatos dinamikus típus kezlésének, amelyek bizonyos esetekben feltételezésekkel élnek a típusokra:" (értékre hivatkozás esetén) ha valami úgy megy, mint egy kacsa és úgy hápog, mint egy kacsa, akkor az kacsa". A mondás Dave Thomas-tól ered, aki a Ruby nyelvet használok közösségének tagja. A típusellenőrzés megértéséhez vegyük a következő pszeudokód példát: var x; // (1) x := 5; // (2) x := "hi"; // (3) A példában, (1) deklaráljuk az x nevet; (2) hozzárendeljük az 5 egész értéket az x névhez; majd (3) hozzárendeljük a "hi"string értéket az x névhez. A legtöbb statikus típus kezelést használó rendszerben a fenti kód töredék érvénytelen, mivel (2) és (3) esetben az x-hez összeférhetetlen típusokat próbálunk kapcsolni. A nem megfelelő típusok használat jelző hiba a fordítás alatt megjelenik, nem generálódik futtatható program. Kontrasztként, egy egyszerű dinamikus típus kezelő rendszer megengedi a program futtatását, mivel az x névvel azonosított hely minden típusa összefér. A megvalósított dinamikus típus kezelő rendszertől függ, hogy hibajelzést ad – "típus hiba" – vagy esetleg hibás kifejezést generál. A lényeg, hogy az esetleges hibajelzés a program futása közben generálódik. Egy tipikus dinamikus típus kezelő rendszer megvalósítása estében a program egy "jelzőt" rendel minden értékhez, ahol a jelző az aktuális típust mutatja, és egy művelet végrehajtása előtt ellenőrzésre is kerül. Például: var x = 5; // (1) var y = "hi"; // (2) var z = x + y; // (3) Ebben a kódtöredékben, (1) az 5 értéket rendeljük az x-hez x; (2) a "hi" értékelt rendeljük az y-hoz; majd (3) megkíséreljük összeadni x-et és y-t. Egy dinamikus típust kezelő nyelvnél, minden érték valójában egy típusjelző és egy érték párból áll, az (1) értékadás létrehozza a (egész, 5) párt és a (2) értékadás a (string, "hi") párt. Amikor a program megkísérli végrehajtani a (3) sort, a nyelv megvalósítása megvizsgálja a párok típusjelzőit egész és string, majd felismeri, hogy az + (összeadás) nem értelmezhető művelet erre a két típusra, ezért hibát jelez. Néhány statikus típus kezelő rendszert használó nyelv létrehoz egy "hátsó ajtót" a nyelvben, hogy a programozónak lehetősége legyen olyan kódot írni, melyen nem történik statikus típusellenőrzés. Például a C és a Java a "szereposztás" angolul cast megoldást alkalmazza. Statikus és dinamikus típusellenőrzés a gyakorlatbanA választás a két ellenőrzési mód között többnyire kereskedelmi megfontolásokon alapul. A legtöbb programozó erősen kitart az „egy minden felett” elv mellett, mások ezt kimondottan korlátozásnak és nehezen tolerálhatónak tartják. A statikus típusellenőrzés a hibákat még fordítási időben találja meg. Ezzel növelhető a program megbízhatósága. Ennek ellenére a programozók tagadják, hogy a típushibák gyakran fordulnának elő, és ezen hibák egy része van csak azért, mert nem vettek figyelembe típusokat. A statikus típusellenőrzés hívei hiszik, hogy a programok megbízhatóbbak, ha a típusokat ellenőrzik, míg a dinamikus típusellenőrzés hívei arra hivatkoznak, hogy a leszállított programok használata önmagában bizonyítja a program megbízhatóságát, és kevés a programhiba. Az erősen típusos nyelvek (mint az ML és a Haskell) pártfogói szerint minden programhibát úgy kell tekinteni, mint típushiba, ha jól meghatározott típusokat használnak a programozók, és a fordító jól következtet. A statikus típusok használatának egyik következménye, hogy a fordított kód gyorsabban végrehajtható. Ha ugyanis a fordító pontosan tudja az adattípust, akkor a gépi kódot hatékonyabban alkalmazhatja. Az újabb statikusan típusos nyelvek fordítói ezt a kézenfekvő lehetőséget ki is használják. Néhány dinamikusan típusos nyelv – mint a CommonLisp – opcionálisan megengedi a típusok meghatározását, éppen az optimalizálás elősegítése miatt . A statikusan típusos nyelvek esetében ez adott. Részletesebben lásd: fordítók optimalizálása. Azok a statikusan típusos nyelvek, amelyekben hiányzik az interfész típus – mint a Java – igénylik a programozóktól, hogy előbb határozzák meg a típusokat, mielőtt azt egy metódus vagy függvény használná. Ez egy kiegészítő információ a program számára, és a fordító nem engedi meg a programozónak, hogy megváltoztassa, vagy ne vegye ezeket figyelembe. Végül is, egy nyelv lehet statikusan típusos anélkül, hogy igényelne típus meghatározásokat, tehát ez nem következménye a statikus típusosságnak. Erős és gyenge típusosságTípusok és a polimorfizmusTípusok
Speciális típusok
Kompatibilitás, ekvivalencia, helyettesíthetőségA kompatibilitás és ekvivalencia kérdése nagyon bonyolult és ellentmondásos, és közvetlenül kapcsolódik a helyettesíthetőség kérdéséhez; más szavakkal: ha adott A típus és b típus, akkor azok azonos vagy kompatibilis típusúak? Használható-e A értéke helyett B értéke? Ha A kompatibilis B-vel, akkor A B egyik altípusa (de fordítva ez nem minden esetben igaz!) – mondja ki a Liskov-féle helyettesítési elv. A típuskonverzió használatával lehetséges, hogy egy típus kompatibilis legyen egy másikkal, egy helyettesítési környezetben. Két különböző típus kompatibilitásra létezik metódus: a nevük (elnevezésük) kompatibilis és a strukturálisan kompatibilisek. Ekkor az "ekvivalencia" és a "kompatibilitás" kifejezések azonos fogalmat takarnak.
A két metódusnak különböző variációi léteznek, a legtöbb (programozási) nyelv ezeknek a technikáknak a különböző kombinációit alkalmazza. Lásd még |
This article is from Wikipedia. All text is available under the terms of the GNU Free Documentation License.
Mercedes Car
This site monitored by SitePinger.net