Sziasztok!

A gondom a kovetkezo:
Van egy igen bonyovalt osztajhierarhiam:

class fo
{
	class al1{...}
	class al2{...}
	class al3
	{
		class al31{...}
		...
	}
	...
	var1, var2, var3...
}

namost a programom csinal tobb peldanyt a fo classbol, es termeszetesen
az egyes al classok csak a sajat fo classukon belul dolgoznak.
Akkor van problema ha nekem mondjuk az al31 egy peldanyabol kellene elernem
mondjuk var1-et. Mert azt ugye nem latja. Erre szeretnek toletek valami frappan
s,
szep, elgans megoldast kapni. Gondoltam ra hogy global-nak deklaralom oket,
de az meg ojan eeee, raadasul nem jo ha tob fo peldanyom van, aztan gondoltam a
rra is
hogy a fo-re mutato pointert megkapja minden al peldany de ez meg lassu es memo
riaigenyes. 
Lehet hogy van ra vmi direkt nyelvi eszkoz is csak nem tudok rola.
Ha valaki segitene, halas lennek. Elore is koszonom: Bagoj

Kedves Programozok!
Uj ember vagyok a listan.
Szeretnem atlatni a szamitastechnika vilagat.
Nem arra vagyok kivancsi, hogy mihez mit kell beklikkelni,
hanem alapjaiban szeretnem erteni, hogy mi micsoda.
Leirom, hogy hol tartok, mi az amit ertek (vagy csak hiszem?),
es aztan hamar eljutok oda, ahonnan nem ertem.
Majd az onnan valo tovabblepeshez kerek segitseget.
Szeretek a kalyhatol indulni:
Volt ZX Spectrum, aztan tavkozlesi technikum (Puskas),
majd 2 ev villamosmernoki a BMEn.
A 8085-os CPU programozasat tokeletesen ertettem.
Programmutato => memoriabol egy bajt be =>
utasitas dekodolas => ALU muvel valamit
vagy csak adatmozgatas tortenik, stb.  Vilagos.
Vilagos a megszakitas vezerles is es az IO egysegek szerepe.
Ott tartunk tehat, hogy a 8085 melleti 64kBban van egy
program, ami vegzi a dolgat, fut.
( Javitsatok ki ha majd rosszul mondom, csak elegem van abbol,
hogy a szamitastechnikat mindig a kozeperol kezdik magyarazni.
En ugy nem ertem, es olyan onzo vagyok, hogy azt szeretnem,
ha valaki onnan meselne', ahonnan kovetni tudom. )

Mar a legelso hazmeretu szgepeknel felmerult az igeny arra,
hogy a memoriat ne mechanikus kapcsolok hada'bol felepitett
ROMbol toltsek fel, hanem adattarolorol (pl. lyukkartyarol).
Ezt a program futasa elott, kulon hardver is megteheti,
de ha a RAMban van egy mindig ott levo loader program,
akkor az az IO portokon at is feltoltheti a RAMot.
(A gep bekapcsolasakor persze vhogy a loadert is be kell tolteni.)
Eljutottunk oda, hogy a szgepen fut egy loader program,
ami csak azt tudja, hogy gombnyomasra betolti a behelyezett
lyukkartyak tartalmat a RAMba, es lefuttatja. Ha gaz van,
akkor lehet resetelni. Felteszem, hogy a loader progit a memoria
nagyobb cimu vegebe tette'k, hogy a "felhasznaloi" progi a nullas
cimre toltodhessen. Jol gondolom, vagy mar nagyon eltevedtem?
 
 Kovetkezo lepesnek kitalaltak, hogy az utasitasokat gepi kodra
forditani mindig macera, es egy hiba is tul sok. Azaz a loader
melle' tegyunk egy assemblert is.
(Nem lehetett semmi assemblert gepi kodban kiizadni, le a kalappal.)
Ha jol gondolom, akkor most ugy nez ki a helyzet, hogy
- szgep bekapcs
- loader a sajat ROMjabol a RAM tetejebe HWesen betoltodik es elindul
- assemblert kartyarol betoltik a RAMba
- assembly nyelvu progit (betuk es szamok sorat) betoltik a RAMba
- elinditjak az assemblert, hogy forditsa le a "betuk es szamok sorat"
    gepi kodra
- a gepi kod a nullas cimtol indulva megjelenik a RAMban
- lefut a gepi kodu progi
    
Felteszem, hogy a sok hibas "felhasznaloi" assembly nyelvu progi
miatt a gep gyakran elszallt, es igy a gepikodu progi futtataskor
a loader-assembler-txt harmast (ami me'g mindig a RAMban volt)
valahogy megvedte'k a veletlen felulirastol.
  Nagy nehezen eljutunk oda, hogy hasznalhato lesz a szgep vmire.
A programunk adatbemenete lehet par kapcsolo,
a kimenete lehetnek lampak. Ha sok szamon akarjuk ugyanazt
a muveletet vegrehajtani, akkor az adatokat sem kell kapcsolokkal
bevinni, olvassuk be lyukkartyarol.
    
Az adatok beolvasasahoz szukseg van egy olyan rutionra,
amit eloszor magaba a programba irtak bele. Mivel a feladat
mas progiknal is (enyhen szolva) gyakran elofordul,
ezert erre a celre kulon program keszult, illetve nem is keszult uj,
mert a loader pont erre van. Hivhatnank lyukkartya-drivernek is.
   Ezzel is sokat kenyelmesedett a programozok elete:
ha adat kell ki vagy be, eleg meghivni az elore megirt rutint,
es megmondani neki, hogy melyik memoriacellakat masolja
a periferian hova. A rutin majd elintezi.
Na itt mar kezdodnek dolgok, amik nem vilagosak.
A periferia is altalaban egy bonyolult mechanika,
amiben szukseg van egy helyi vezerlesre, pl flopinal
melyik savon legyen a fej, stb., ezeket ugyebar mind el kell rejteni
a CPU IO egysege elol. Ha szabvanyos a csatlakozasi felulet, es az,
akkor az IO-t nem erdekli, hogy a periferia hogyan oldja meg a feladatat.
Akkor viszont mibol is all egy pl. flopi driver? Gyakorlatilag
semmibol, egy sima ciklus par MOV utasitassal a koze'pen, nem?
Ez az a nagy kunszt, amit inkabb meghivnak, semhogy beletegyek
a "felhasznaloi" progiba kozvetlenul? Am legyen.
De akkor miben kulonbozik egy flopi driver egy lyukkartya drivertol?
Csak annyiban, hogy eppen melyik periferia melyik portra van dugva?
A flopi fejet vezerlo progi ugye nem szamit drivernek?
Vagy a lyukkartyak koraban me'g nem volt szabv. csatl. felulet es az
olvaso mechanikanak minden nyuget-bajat a felhasznaloi szoftver
volt kenytelen kezelni?
Innentol egyre homalyosabb, erositsetek meg, hogy eddgi stimmel-e.
Sorlimit miatt mara ennyi. Koszonom szepen elore is,
BM