1. |
Cpp kerdes megint (egymasba agyazott classok, vcpp6) (mind) |
36 sor |
(cikkei) |
2. |
szamtek alapjai - szegmens + offszet (mind) |
86 sor |
(cikkei) |
3. |
Re: Delphi - Paradox - ODBC (mind) |
10 sor |
(cikkei) |
4. |
Re: C# website (mind) |
7 sor |
(cikkei) |
5. |
DirectDraw7 vs. Direct3D9 (mind) |
13 sor |
(cikkei) |
|
+ - | Cpp kerdes megint (egymasba agyazott classok, vcpp6) (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Sziasztok, egy par hete mar irtam es kaptam is valaszokat, amiket megegyszer ko
szonok szepen, de nem igazan megy a dolog, ugyhogy megkozelitem ujbol.
Szoval adott: class class1{int var1; class class2{...}; class2 myClass2;};
Nos azt hogyan tudom elerni hogy myClass2 (vagy egyaltalan egy class2 ami class
1 peldanya) lassa var1-et? Javasoltatok a friend-et, de ha joltudom akkor az cs
ak a private feloldasara valo, tehat a myClass2 meg nem tudja var1 cimet. Aztan
lehet azis hogy ms specifikus bar nemhiszem, egyszoval a kovetkezo hibauzenett
el van bajom: member from enclosing class is not a type name, static, or enumer
ator
Ezt ertem is, es teljesen logikus... csak azt nem ertem hogy miert nem lehet ve
le valamit csinalni. Ezekszerint mindenkeppen muszaly a class2 konstuktoranak c
lass2(class1* pParent) formajunak lenni, ahol atadom a szulo (vagy micsoda) cim
et? Ja es akkor arrol nem is beszelve hogy utana indirekcioval kell pParent->va
r1 modon megcimezni azt a csorikam valtozot. Itt ez nem lenyeg, de ha mar 15-16
lepcsom van akkor nem valami takarekos modszer, raadasul debugolhatatlan etc.
Nem lehet ezt egyszerubben? Nemis tudom, mondjuk ojan extern szeruen, hogy a va
r1-t deklaralom class2-n belul is. Vagy ha class2-n belul var1-t staticnak dekl
aralom az mar majdnem jo, mert 1 var1 van, csak eppen nem az amelyik nekem kene
:o/ Remelem mostmar rendesen ertheto a problemam, es tudtok segiteni.
Elore is nagyon koszonom, udv: Bagoj
p.s.: bocs ha meg mindig kicsit keverem a dolgokat, a szulo meg ijesmi dolgokna
k itt semmi kozuk a oroklodeshez csak az egymasbaagyazasban van hierarchia.
Hogy egy kicsit szemleletesebb legyen:
class game
{
int gamespeed;
class player{int pos; void move();};
player player1, player2;
}
void game::player::move()
{
pos += gamespeed * 5; //na pl ijesmire kellene :o(
}
|
+ - | szamtek alapjai - szegmens + offszet (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Kedves Medve !
Koszonom, hogy felhivtad ra a figyelmemet.
Kell 20 bit, ertem. Azt, hogy ehhez miert nem fert el +4 vezetek,
azt nem, de am legyen. Ha +4 nem fert el, akkor +16 plane
nem ferhetett el, ezek szerint marad 16 cimvezetek es a
cimzes ketfordulos. Ha ketfordulos, akkor ennyi erovel
a 32bites cim is elferhetett volna, legfeljebb az elso 12 bit
par evig me'g nulla marad. Na mindegy.
> a vegso cim ugy alakul ki, hogy a szegmens erteket
> megszorozzuk 16-tal, es utana hozzaadjuk az
> offszetet.
Ez kristalytiszta (felteve, hogy nem kerdezzuk, miert
nem tesszuk siman egymas melle oket).
Jol megizzadtam, mire megertettem,
ugyanis keveredik az elso es masodik fogalma.
Tehat van egy 20 bites regiszter a memoria elott,
amibe eloszor beirodik a "masodik" nevu
de idoben elsokent kiadott 16 bit.
Ez a szegmenst hatarozza meg, ezert balra kell tolni
4 bitet. Jobb oldalt nullak jonnek be.
Ehhez az immaron 20bitesre hizott szamhoz hozzaadjak
az "elso" 16 bitet es igy jon ki a vegleges cim.
>igy aztan azt talaltak ki, hogy a masodik 16 bitet
>elcsusztatjak 4 bittel balra.
>viszont nem tudunk minden egyes bajtot
>kulon megcimezni, kell hozza az elso 16 bit is.
Igen, szoval az "elso" 16 bit jon masodiknak...
Miert cserelted meg? Csak eliras vagy van ennek
valami magyarazata?
>1234:0005
>1230:0045
>1200:0345
>1000:2345, ezek ugyanazt a bajtot jelentik.
Azaz felfogas kerdese, hogy keves szegmenssel
es sokbites offszettel dogozunk, avagy sok a szegmens,
de mindegyik csak keves bajtot tartalmaz.
A vegeredmeny ugyanaz.
Akkor ezt nagyjabol ertem. En a cimek irasanal valoban
nem torodtem ezzel, es ha nem kifejezetten ez a lenyeg,
akkor egyelore eztan sem szeretnek ezzel faradni.
Pusztan az attekinthetoseg keveert tagoltam negyesevel.
Koszi szepen.
-----------------------
A videokartyas levelig addig is osszefoglalom, mi volt eddig.
A kalyhatol: volt a CPU+RAM, ami egy porton at kommunikalt
az adattartoloval (ir+olv), ennek kezeleset intezo rutint ROMba tettek,
es a user progi meghivhatta. A flopi/lyukszalag buta.
A flopivezerlo kartya az adat+cim+irq+io/m buszon log, dekodol(kikapuz)
illetve megszakitaske'res eseten megrantja a busz egyik labat.
Ennyi erovel barmelyik porton is loghatna
(kicsit mas rutinnal mert kell az irq).
Kommunkacionak volt me'g konzol, pl. 8db kapcsolo + bevitel gomb.
Ezzel egyesevel lehetett beirni a gepi kodu programot. Nullatol,
mert valszeg nullatol volt megirva. Ezt kesobb assemblerrel
transzponalni lehetett. Az assembler fo funkcioja persze a forditas volt,
es ehhez be kellett jutattni a gepbe az assembly nyelvu progit.
Ehhez volt par trivialis lehetoseg, ebbol a legfejlettebb a
kesz billentyuzet, ami magatol eloallitja a karakterek kodjat, es
szabvanyos IO feluleten at (megfelelo rutin segitsegevel) beirja a RAMba.
Az igy bepotyogott (esetleg lyukszalagrol betoltott) txt-t forditotta
az assembler es persze transzponalta a cimeket is.
Az visszajelzes igenye miatt a billentyuzetet kiegeszitette'k egy
villanyirogeppel, ami mar nem csak azt irta ki, amit a user begepelt,
hanem a szgep altal kuldott karaktereket is.
Kesobb ez a villanyirogep okosabb lett, egesz sorokat lehetett
elore beirni, mielott elkuldte a szgepnek es a sor beirodott a RAMba.
Kovetkezo lepesnek kette valt a billentyuzet es a kiiro resz.
A billentyuzet kulon IO-n es kulon rutinnal kommunkalt,
akarcsak a kiiro resz. Az elozo csak olvashato periferia,
a kiiro csak irhato periferia lett.
A papirra iro periferiat lecserelte'k kepernyosre, de a kepernyorol
ugyebar mindig eltunik ami kiirt az elektronsugar, ezert folyamatosan
frissiteni kell, meg ugye nem is betunkent rajzol, hanem soronkent,
szoval mindenkeppen kellett egy kulon memoria neki,
videoRAM tartalma = kepernyotartalom, 1bit = 1pixel. (kezdetben...)
Ezt a RAMot a helyi HW csak azert olvassa, hogy az elektronsugarat
vezerelje vele (egyelore vagy kiolt vagy nem).
Folyt. kov. holnap. BM
|
+ - | Re: Delphi - Paradox - ODBC (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Szervusz!
Szerintem ne fáradozz azzal, hogy az ODBC-s adatforrásokat BDE-Admin ban próbál
d megnyitni. Nem ugyanaz a világ. Vagy ODBC vagy BDE. Delphi-n belül sokszor mé
g arra sincs szükség, hogy adatborrást definiálj. Erre való a TDatabase.
Ha mindenképp adatforrás kell, akkor inkább a BDE-ben hozd létre.
ZéZé
(webes bekuldes, a bekuldo gepe: 193.6.135.71)
|
+ - | Re: C# website (mind) |
VÁLASZ |
Feladó: (cikkei)
|
> Figyelmébe ajánlanám az olvasóknak egy a C# programozással kapcsolatos
> nemrég indult magyar websiteot:
> www.csharp.hu
Csak a freeweb logo lathato, magabol az oldalbol semmi nem latszik. A
forras alapjan gondolom, hogy valami automatikus atiranyitast hasznal,
de az nem mukodik.
Kaphatnank kozvetlen mutatot?
|
+ - | DirectDraw7 vs. Direct3D9 (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Hello!
Nezegettem az uj DirectX leirasat, es a 8-as verzio ota
egybeolvasztottak a Direct3D-t, es a DirectDraw-t. A kerdesem az lenne,
hogy ha pusztan, es szigoruan 2D alkalmazast szeretnek irni, akkor
melyik az elonyosebb: hogy az uj Direct3D-t hasznalom, vagy a regi
DirectDraw7-et? Egyaltalan lehet a Direct3D-t ilyenre hasznalni?
Hatranyok nelkul? Pl. nem nagyon lattam a regi Blit eljarasokhoz
hasonlot az uj doksikban. Ha valakinek van tapasztalata, akkor irhatna
errol egy par sort!
Koszi
Gubi
|
|