#76
> adatszerkezetből adatszerkezetbe mutató adat elérési ideje korlátos, ha az elemek száma is korlátos.
Na, hat nagyjabol ezt probalom neked elmagyarazni. Ha pedig ezek az eltero adatszerkezetek egyetlen kozos grafba vannak szervezve akkor annak az egyes pontjai koze vektorok irhatok fel melyeken keresztul a leghosszabb ut determinalhato. (tovabbra is veges adatszerkezetekrol beszelunk)
> Determinisztikus esetekre PLC-t használnak
Altalanositas. Hol? Ipari kornyezetben lehet, de ennek semmi koze a temankhoz.
> RTTI működése a fordító kezében van. Minden típushoz hozzárendel egy bizonyos Typeid rekordot, melyben a típus sorszáma szerepel néhány más adat mellet. Ezt az értéket hasonlítja össze a beazonosítani kívánt típus azonosítójával.
A tipusindexeles alapveto dolog.
> sőt, léteznek advanced keresési technikák, ahol többezer adat közül max. 8-10 összehasonlításból megmondható a típusról, hogy megfelelő -e.
Ez szinten nem ujdonsag.
> Aztán a VMT-t meg jó is hogy nem írtad le. Mert amit te mondasz, az nem virtuális metódus lesz, hanem static osztály-tagfüggvény
Ha tovabbra is kenyszerszeruen egy altalad valasztott konkret hagyomanyos nyelvi fordito, netan binaris targykod architektura sajatossagait alkalmazod altalanositasban.
> mihelyst átadod az objektumod egy másik osztálynak, máris buktad az osztálytagfüggvény címét.
Es itt tovabbra sincs kiemelve, hogy mindez a hagyomanyos operacios rendszereknel megszokasbol alkalmazott redundans osztaly/objektum nyilvantartas problemaibol adodik.
Vegyel alapul egy terminalszervert ahol - mondjuk a gyakorlati pelda kedveert - 100 user van bejelentkezve es mindegyik 2 peldany Firefox-ot futtat. Az processzenkent (ures bongeszoket feltetelezve) nagyjabol 70MB, 200x70MB az 14GB-nyi lefoglalt memoria 200 redundans adattal ami 14GB helyett 70MB-tal is felirhato lenne ha van a hatterben egy kozos adatszerkezetbe szervezett egyszeru, kulturalt memoriahozzaferes-kezelesi strategia. Ha a merevlemezen rendelkezik egy futtathato binaris futtatasanak jogosultsagaval egy adott felhasznalo, akkor evidens, hogy ugyanannak a memoriaba mar korabban betoltott peldanyahoz is kell hogy jogosultsaga legyen, (!!) ha csupan az egyes felhasznalok altal folytatott tevekenyseg van kulon memoriateruleten kezelve es szeparalva. Ugyanezzel a modszerrel logikailag barmilyen eroforras megoszthato konkurrens peldanyok es felhasznalok kozott, csupan konfiguralas kerdese.
> először is [b[biztos, hogy ezzel még nem lesz típusbiztos a címtartomány kezelésed.
Mivel?
> A típusbiztosság megköveteli, hogy a forrás és a cél típusa megfeleltethető legyen egymásnak
Igen, ezt jelenti az amit irtam: "Realtime tipusazonositas."
> közös protokolokról nekem az usb jut eszembe. ott egy halom deszkriptor létezik, aminek a kitöltögetése a -közös protokol miatt- jókora erőforrást visz el.
Es mekkora eroforrast visz el ha pont-pont kozti kapcsolatokra tucatnyi protokollt hasznalunk, netan egyikbol a masikba atjarunk?
Melyik eroforrastakarekosabb? Egy jol atgondolt azonos protokollon keresztul barmilyen digitalis/digitalizalt adat tovabbitasa, vagy tucatnyi protokollt megirni, karbantartani, memoriaban tartani, egyidoben futtatni es netan egyikbol a masikba konvertalgatni?
> Na persze, és így lesz egy multitask operációs rendszerből multi threaded single task. Ami nagyjából semmit nem ér, mert ad egy nagy pofont az adatbiztonságnak, a szálbiztonságnak
He?? Tobbek kozott eppen ezt hivatott garantalni azaltal, hogy a kozos protokollok (ertsd: kozos atjarasi pontok) miatt nem kell bloatware-eket karbantartani, nem kell 25-szor ellenorizni egy felhasznalo jogosultsagat ugyanahhoz az eroforrashoz, mert minden felhasznalo tevekenysege ugyanazon a grafon megy keresztul. Ha mar az elso lepesnel elakad a masodik kriteriumot meg sem kell vizsgalni. Es ez igaz barmely szituaciora, legyen az az eroforras akar egy memoriaterulet, egy tetszoleges periferia, egy hattertaron tarolt adat, vagy mittomen egy ugyviteli szoftver altal tarolt adatbazisrekord.
> De hogy OS-t nem írtál még sem embedded sem PC környezetben az biztos.
En nem igy emlekszem.
> Tudod már miért akadt el az OO alapú Linux fejlesztése ?
#76