Generics hogyan

A Generics megvalósítása a .NET-ben a 2.0-és verziótól a Java-ban pedig a JDK 5.0-tól használható minden programozó számára (a Java-ban eredetileg ez "Pizza" kódnéven futott – nyamm nyamm). Ne tessék megijedni, eszem ágába sincs a generics lényegét most elmagyarázni, megteszi azt helyettem számos könyv és weboldal. Inkább nézzünk egy picit a színfalak mögé és vizsgáljuk meg azt, amiről oly kevés szó esik. Vajon a C++ esetén és a .NET-ben hogyan valósították meg ezt az egészet? Hékás, érdekel-e valakit egyáltalán? Akit igen, az jó alaposan melegítse be az agysejtjeit.

 

Sokszor elhangzott, hogy semmi újdonság nincs modjuk a C# generics megvalósítsában, hiszen a C++ template módszere már nagyon régóta biztosítja ezt. Igen-igen, de azért a két megvalósítás között rettenetesen nagy különbség van (vagy legalábbis elég sok). A C++ nyelven írt template-ek inkább olyanok, mint a marók, amikkel lehet generics-szerű viselkedést is szimulálni, a C#-ban viszont inkább hasonlítanak osztályokra (vagy tán azok is), melyeket jól lehet paraméterezni. C++ esetén meglehetősen korán, fordítási időben, míg C# esetén jórészt futás előtt/alatt/közben kerülnek a helyükre ezek a kódok. A C# generics megvalósítás – a .NET jellegéből adódóan – erősen típusos (ellenőrzött), míg a C++ kevésbé, ezért ezt inkább nevezzük őt most gyengén típusosnak.

 

A C++ fordító a template használatakor nem fordítja le a template kódot különálló bináris kóddá, hanem úgynevezett inline kódként behelyezi minden hivatkozott előfordulás helyére (lehet, hogy nem mindegyik ilyen, de amiről én tudok, az igen). Ráadásul, amikor valaki használ egy efféle megoldást, akkor a fordító típus-specifikus inline kódot helyez be oda, ahova az előzetes specifikációnak megfelelően erre bizony szükség van. Később, a C++ linker dolga lesz, hogy feloldja ezt a helyzetet, amit nem minden esetben sikerül neki jól megoldania. A megoldásból adódik, hogy sok esetben a kód terjengőssé válik, illetve a betöltési idő és a memória helyfoglalás is növekszik.

 

A .NET 2.0-ban a generics-nek natív támogatása van az IL (Intermediate Language) és a CLR (Common Language Runtime) jóvoltából. Amikor valaki mondjuk C#-al lefordít egy szerver oldali generics kódot (szerver oldalnak most azt a kódot nevezzük, akit majd egy kliens használni fog valamikor, amikor pl.: egy osztályt pédányosít), a fordító elkészíti belőle az IL kódot úgyanúgy, mint bármely más típus esetén. Azonban az IL kód ezen a ponton tartalmaz bizonyos paramétereket és helyőrzőket az aktuális típus specifikációk számára, a generic szerver oldali kódjának metaadata pedig még további általános információkat is letárol.

 

Példa egy generic osztályra és annak használatára:

public class Verem<T>

{

  T[] m_Adatok;

 

  public void Betesz (T adat)

  {…}

 

  public T Kivesz()

  {…}

}

 

Verem<int> verem = new Verem<int>();

verem.Betesz(1);

verem.Betesz(2);

int szam = verem.Kivesz();

Természetesen a szerver oldalhoz kapcsolódó kliens alkalmazás (a generic típusra hivatkozó, példányosító kód) fordításakor, annak C# fordítója használja ezeket a generic metaadatokat, hogy kellőképpen biztosítsa a megfelelő típusbiztonságot. Amikor a kliens megmondja, hogy az általános (mondjuk <T> helyett) pontosan milyen típussal szeretné létrehozni a példányt (mondjuk <string>), akkor a fordító lecseréli a szerver oldali metaadatokban az általános generic típus jelölést a pontosan megadott típusra (vagyis a "T"-t —> "string"-re).

 

No, de vajon hogyan lesz ebből a szerver oldali IL kódból igazi gépi kód? Attól függ. Ha a kliens érték típust határozott meg (pl.: int, string), akkor a JIT fordító egyszerűen lecseréli az általános vagy formális típusjelet a tényleges vagy aktuális típusra, majd lefordítja az IL kódot gépi kódra. Természetesen a JIT fordító nyilvántartja, hogy ő egyszer ezt már megtette, és amikor legközelebb ugyanezt a feladatot kapja, akkor már nincs más dolga, mint visszaadnia a korábban lefordított gépi kódra való hivatkozást. Nincs kód terjengősség, nincs plusz memóriafoglalás.

 

Ha a kliens a generic példányosításkor referencia típust határozott meg (pl.: Array, Class), akkor a JIT fordító lecseréli az általános típusjelet object típusra, majd lefordítja az IL kódot gépi kódra (ne felejtsük el, minden referencia típusnak az object az ősosztálya, ezért bárhol, ahol ilyen típus van az object is állhat helyette). A továbbiakban ugyanaz történik, mint ami fentebb már az érték típusnál említve volt. A JIT egyszerűen újrahasznosítja a meglévő gépi kódot (nincs heap növekedés, nincs típuskényszerítés).

 

Ezzel a megoldással nem szükséges az érték típusok ki és bedobozolása (boxing/unboxing), nem kell semmiféle típuskényszerítés, emiatt nem lesz kód terjengősség se függetlenül attól, hogy a generics esetén milyen típust használtunk. Mivel midezen kényszerítő és kellemetlen mellékhatások nem léteznek, így érték típusnál megközelítőleg 200%-os, referencia típusnál pedig majd 100%-os sebességnövekedést lehet elérni (már, ha az alkalmazás jól van megírva).

 

Érdemes így a vége felé egy mondatot szentelni a Java generics megvalósítására is. Ha egy mondantba kellene összefoglalni, akkor azt mondanám van is, meg nincs is. A Java generics, mint már említettem "Pizza" kódnéven futott és egy Martin Odersky nevű fickó kezdeményezése volt (később átnevezték GJ-re, majd ezután került be a Java nyelvbe). Mivel a fő tervezési célja az volt, hogy az új generics-ek a régebbi JVM-eken is működenek, így a képességei meglehetősen korlátozottak. Csak egy példa, aztán be is fejezem. A Java generic formális típust az Object aktuális típusra cseréli le. Ez önmagában még nem probléma, kivéve az egyszerű típusoknál (pl.: int, String), ahol ugyanúgy az Object-et használja, ami viszont be meg kidobizolással jár (boxing/unboxing). Szóval erősen teljesítményrongáló hatása van. Más hátránya is van, de most már nem élek vissza a türelmes olvasó idejével. Ennyi elég is volt mára.

Szegény gazdagok

4,29 milliárd dollár, azaz 618,1 milliárd forint nettó profit. Így játsztok ti…

 

"A Microsoft a dotkom-láz óta nem növekedett ilyen gyorsan, a cég negyedik pénzügyi negyedévének bevétele 18 százalékkal múlta felül a tavalyit, miközben a nettó profit több mint 40 százalékkal növekedett. A világ legnagyobb szoftvergyártójának éves forgalma elérte a 60 milliárd dollárt."

 

Részletek itt.

Riadalom a VMware-nél?

Azt írják, hogy váratlanul lemondott a VMware elnök-vezérigazgatója. A fene tudja mit jelenthet ez, de talán pár hónap múlva majd kiderül.

 

"A pénzügyi elemzők körében általánosan elterjedt vélekedés, hogy a Microsoft tervezettnél hat héttel korábban piacra került Hyper-V virtualizációs köztesrétege jelentős konkurencia a VMware számára és komolyan veszélyezteti a vállalat piaci pozícióit — ez állhat a módosított előrejelzés hátterében is. Egyes vélekedések szerint a Hyper-V el fogja hódítani a kis- és középvállalatokat, míg a nagyvállalatok rövid távon kitartanak a VMware mellett."

 

Részletek itt.

“Ez már Európa?”

 

 "Lassan lépked a fűben
  A vak zenészek kara.
  Mondjátok emberek,
  Ez már Európa?"

 

 – Hobo Blues Band: Vadászat –

 

Hogy miért írtam én most ezt? Hát ezért: Megállok lihegve: Páris, Páris (ha végigolvastad, akkor biztosan megérted)

A nagy durranás

Hosszú, majdnem 3 hónapos előkészítő munka és sok-sok küzdelem árán néhány nappal ezelőtt elnyertünk egy üzletet. Egy nagyon ismert, sokak által naponta használt magyarországi "valamiről" van szó (a témát nem szeretném megnevezni). A munka nagyon nagy, a projekt megközelítőleg 300 millió forint értékű (kb. ennyi vándorolna a cégem zsebébe úgy 1,5 – 2 év múlva).

 

A feladat az, hogy ennek a "valaminek" a teljes szoftveres megvalósítását mi fejlesszük ki. Természetesen ügyviteli és termelésirányítás jellegű szoftverrendszerről van szó (jó kis műszaki jellegű szoftverekről én csak álmodozni szoktam, csinálni aligha), mely legalább 8 önálló, de egymáshoz kapcsólódó modulból és több száz funkcióból áll. Vastag kliens alapú és webes megvalósítások is lesznek. Az adatbázis-kezelő és az üzleti elemzést támogató csomagra az Oracle-t szántuk (mint eddig majdnem mindenhol). Az ügyviteli részek fejlesztői környezete és technológiája pedig olyan alapokon nyugszik, melyeket az elmúlt 15 évben már kellőképpen bombabiztosra csiszoltunk (az ember nem ugrabugrál folyton a nagy szoftvergyártók egyik ötleteiről a másikra, hanem használja amije van és ami már jól bejáratódott). A hozzátartozó webes portál modul viszont .NET alapú lesz (jelenleg ebben van nagyobb tapasztalatunk).

 

A kezdet kezdetétől részt kellett vennem a pályázati szakaszban is úgy, hogy a beadandó anyag szoftveres-műszaki fejezeteinek a kidolgozása teljes egészben rám maradt. Ott voltam több bemutatón meg tárgyaláson, ahol bármi áron meg kellett győzni az ajánlatkérőt, hogy semmi kétsége ne legyen afelől, miszerint az én cégem a legjobb a témában (több pályázó is volt, de a küzdelemből – némi rásegítéssel – mi kerültünk ki elsőnek).

 

Sajnos azonban még a várható 300 millió forintos bevételtől se ugrálok az egekbe, mivel tudom, hogy ez a pénz éppencsak fedezi fogja a fejlesztés, bevezetés, hardver-szoftver és szolgáltatási költségeit. Arról nem is beszélve, hogy nagy felelősség, komoly munka, amelyen óriásit lehet bukni. Főleg azért, mert az üzemeltetést végző csapat nem minket szeretett volna győztesnek látni (hanem inkább mást – gondolom), csak szerencsére nem ők, hanem a tulajdonosi kör döntött. A felmérési munkálatok elkezdődtek, vagy úgy is mondhatnám, ahogy egy nagy magyar mondta 52 évvel ezelőtt: "Csapataink harcban állnak…" (szó szerint)

E-mail cím

Elhagytam a T-Online internetszolgáltatót (az okokat inkább nem írom le, mert beperelnének hitelrontásért), és átváltottam az UPC-re. Az email címem a jövőben a putabout@upcmail.hu lesz.

 

Jó munkát, jó egészséget kívánok mindenkinek!

Webszerverek

Nem a pillanatnyi helyzet, hanem inkább az irányzat a mérvadó. Pedig ez egy Netcraft felmérés.

 

 

Active sites

 

Developer    May 2008 Percent   June 2008  Percent  Change
Apache     32,839,213  48.04%  33,419,978   46.97%   -1.07
Microsoft  24,040,260  35.17%  25,292,798   35.54%    0.38
Google      6,592,598   9.64%   7,256,264   10.20%    0.55
Sun           173,679   0.25%     176,726    0.25%   -0.01
lighttpd       92,041   0.13%     100,536    0.14%    0.01

 

Részletek itt.