1. |
Re programozas (mind) |
51 sor |
(cikkei) |
2. |
Proci elnevezes (mind) |
16 sor |
(cikkei) |
3. |
Re: Ablakkezelesi modszer tipp (mind) |
29 sor |
(cikkei) |
4. |
Re: Miert nem helyes a GOTO? (mind) |
6 sor |
(cikkei) |
5. |
Re: RE: forditas (mind) |
15 sor |
(cikkei) |
6. |
Re: Assembly (mind) |
32 sor |
(cikkei) |
7. |
Re: Miert nem helyes a GOTO? (mind) |
61 sor |
(cikkei) |
8. |
Re: forditas (mind) |
67 sor |
(cikkei) |
9. |
Re: Assembly (mind) |
9 sor |
(cikkei) |
10. |
Re: Soros port programozasa (mind) |
12 sor |
(cikkei) |
11. |
Re: forditas (mind) |
65 sor |
(cikkei) |
12. |
Re: pic (#2) <-- soros port programozas -->Mc (mind) |
46 sor |
(cikkei) |
13. |
Re: Windows task leloves (mind) |
13 sor |
(cikkei) |
14. |
Re: CHM (mind) |
12 sor |
(cikkei) |
15. |
Delphi scanner komponens (mind) |
11 sor |
(cikkei) |
16. |
HELP - Programozasi fogalmak (mind) |
106 sor |
(cikkei) |
17. |
Miert nem helyes a GOTO? (mind) |
43 sor |
(cikkei) |
18. |
Re: Goto? (mind) |
15 sor |
(cikkei) |
19. |
Re: Assembly (mind) |
14 sor |
(cikkei) |
20. |
Re: Miert nem helyes a GOTO? (mind) |
15 sor |
(cikkei) |
21. |
Re: Felbontas csokkentes (mind) |
57 sor |
(cikkei) |
22. |
PIC prg + forditas (mind) |
60 sor |
(cikkei) |
23. |
T3E (mind) |
6 sor |
(cikkei) |
24. |
Re: *** HIX CODER *** #658 (mind) |
11 sor |
(cikkei) |
25. |
Re: Soros port programozasa (mind) |
19 sor |
(cikkei) |
26. |
Visual C++ COM tanfolyam (mind) |
14 sor |
(cikkei) |
27. |
CAB-error (mind) |
3 sor |
(cikkei) |
28. |
Re: CHM (mind) |
18 sor |
(cikkei) |
|
+ - | Re programozas (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Hello Stenya
> Ilyen progit kellene irni, ami ilyet tud:
> -dinamikus adatszerkezet
Az adatnak a hely ( a memoriaban ) futasi idoben foglalodik, mig a
statikus
adatoknak ( pascalban a foprogram VAR szekcioja,) forditasi idoben.
A statikus adatok az ADAT szegmensben kapnak helyet ( max 64 K), mig a
dinamikus
adatok a HALOM ( Heap ) reszen. Itt le lehet foglani futasi idoben helyet
egy adatnak ( new , getmem )
amelyet fel is lewhet szabaditani ( dispose , freemem ), ettol dinamikus.
> -pointerek
> -láncolt lista { egy dinamikus adatszerkezet , az allabi
forrasban egy duplan lancolt lista van }
> assign(sz,'d:\prg\pascal\sajat\libra');
> reset(sz);
> i:=0;
> new(fej); { dinamikus hely foglalas ( futasi idoben ) }
> fej^.eloz:=nil; { nincs elozo elem }
> fej^.kov:=nil; { nincs kovetkezo elem }
> fej^.adat.peldsz:=0; { nincs informacio }
Ez egy duplan lancolt ures fejelt lista letrehozasa. Az ures lista
tartalmaz egy elemet ( amely nem
hordoz informaciot), hogy a listaval vegzett muveletek egyszerubbek
legyenek ( uj elem felvitele,
letezo elem torlese )
> akt:=fej;
> while not eof(sz) do
Ugy nez ki, hogy az aktualis elem utan felfuz egy uj elemet, amelyhez az
informaciokat
egy szoveges file - bol olvassa.
> elemt=record { a lista egy eleme }
> adat: konyv
> eloz,kov: mut;
> end;
B. Arpi
|
+ - | Proci elnevezes (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Hello
>hogy pontosak legyunk, az cim felso bitje az elojel...
>tehat, az ugras a kovetkezo utasitas elejetol szamitott
>-128 es +127 tartomanyban barhova lehet 80386-ig...
Ezert hivjak a 386-os procit 386-nak?...
>Ez nem minden processzoron igaz, pl. az Intel 80x86-osokon _nem_! Hi
...es a 80x86 mire vonatkozik?
Tudna vki errol felvilagositast adni,
mire vonatkoznak ezek az elnevezesek?
Udv
Akos
|
+ - | Re: Ablakkezelesi modszer tipp (mind) |
VÁLASZ |
Feladó: (cikkei)
|
+1 5let:
Veszunk a kepernyonek megfelelo meretu teglalapot. Ezutan elindulunk az
ablakokon lefele, es "kivonjuk" az ablakok altal takart teruleteket a
kepernyo teruletebol.
A kivonas teglalapok eseten azt jelenti, hogy a kepernyo teglalapjat
felosztjuk legfeljebb 5 teglalapra, amibol az egyik pont a legfelso ablak
kepernyon belul eso resze. Ezt a teglalapot kidobjuk es a maradek negy adja
meg a legfelso ablak alatti ablakok frissitendo teruleteit.
Egyre lejjebb haladva az ablakokon egyre pontosabban hatarozodik meg a
frissitendo terulet, mig vegul elerjuk a frissitendo ablakot.
Most vannak olyan teglalapjaink amik a lathatosagot adjak meg, meg van egy
olyan ami a teruletet. Csak azt a teruletet kell frissiteni, ami lathato es
az ablakban van, ezert ki kell szamolni a lathatosagot megado teglalapok es
az ablak teruletet megado teglalap kozos reszeit, ami 0 vagy tobb teglalapot
fog eredmenyul adni. Ha 0, akkor nem kell frissiteni az ablakot, mert nem
latszik belole semmi.
Egy rajzolo muvelet csak olyan helyre rajzolhat, ami egy teglalap belsejeben
van, vagyis "vagni" kell a grafikai muveleteket az eredmenyul kapott
teglalapokra.
(En se pont igy csinalnam, de igy volt egyszerubb megfogalmazni :)
z2
|
+ - | Re: Miert nem helyes a GOTO? (mind) |
VÁLASZ |
Feladó: (cikkei)
|
> irja).... Talan nem veletlen, hogy a JAVA-ban is csak foglalt szo a goto
> es nincs implementalva.
Van helyette mas, 'break cimke' vagy valami ilyesmi.
z2
|
+ - | Re: RE: forditas (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Kedves Rudnai Tamas,
Mielott tenyleg eloallitanal egy 4 kb-s utasitast,javaslom,olvasd el,hogy
mikor keletkezik int 0x0D (a felreertesek elkerulese vegett: GENERAL
PROTECTION FAULT:)
(ha gonoszkodni akarnek,azt mondanam,hogy megint megsporolhattal volna
ket-harom kilowatt aramot a cegnek..)
udvozlettel
Demeter Zoltan
(ui:igen,tudom,a kilowatt nem az aram mertekegysege:)
|
+ - | Re: Assembly (mind) |
VÁLASZ |
Feladó: (cikkei)
|
>Barmilyen programnyelvben lehet irni gepi
>vagy assembly kodot, ertelemezi a fordito?
>A C-be ugy tudom lehet.
A legtobbe lehet kulso ASM kodot illeszteni, es sokban van inline ASM is.
A standard C (ertsd ANSI C) nem tudja az inline ASM-et, de pl. Borland igen.
Nyilvan C fordito / linker fuggo, hogy kulso ASM-et tehetsz-e hozza (meg nem
lattam olyat, amihez nem).
Gepi koddal talan mindegyiket meg lehet eroszakolni (pl. Borland cuccok
hivatalosan is tamogatjak) -- ha a kodszegmens nincs iras ellen vedve, akkor
barmit megtehetsz, pl. egy gepi kodu rutint a megfelelo helyre beszurhatsz. Ill
.
ha az adatszegmensre megengedett a futtatas is, akkor is ugyanez a helyzet. Vag
y
ha tudsz lefoglalni olyan memoria blokkot, aminek az engedelye jogositvanyt ad
a
felhszanalonak mind irasra, mind pedig futtatasra. (DOS alatt ugye nincs
engedelyezes, WIn alatt nem tudom, Linux alatt meg lehet csinalni, de nincs ra
szukseg -- kulso ASM programot szerkeszthetsz a programodhoz).
Ha pedig maskent nem megy, ASM-ben irsz egy programot, leforditod
vegrehajthatova, majd elteszed az adatszegmensbe, amikor kell kiteszed file-ba,
es lefuttatod... nem tul szep megoldas, 99.999999%-ban nincs erre szukseg.
Tamas
Tamas Rudnai / Sophos Plc
mailto:
http://www.sophos.com
|
+ - | Re: Miert nem helyes a GOTO? (mind) |
VÁLASZ |
Feladó: (cikkei)
|
>vagni. A strukturalt programozassal nehezen fer ossze. A ciklusokbol,
>programegysegekbol valo ugralgatasnak a lehetosege rengeteg
>hibalehetoseget rejt magaban, ezaltal kevesbe stabil progikat irhatunk.
Egyetertek, bar nyilvan ugyanez elmondhato a "fejlett" ciklusokra is (for, while
stb...). Ha valaki nem jol fogalmazza meg a kilepesi felteteleket, akkor
fejreall a program. Talan epp emiatt szoktak break-et es continue-t hasznalni a
ciklusokon belul, ami ha kicsit tagabban ertelmezzuk a GOTO-t, akkor egy cimke
nelkuli GOTO, nem? Ugyanigy ha valaki egy exit system call-t hajt vegre a
program kozepen, az GOTO END-nek felel meg, nem? Vagy funkcio kozepen return stb
stb stb.
Nem is beszelve a magasszintu nyelvekben kevert blokkokba foglalt utasitasokrol
:
C-ben is, es Pascal-ban is a felteteles utasitasok es ciklusok utan egyetlen egy
utasitast irhatsz, ami persze lehet egy blokkba foglalt utasitas-sorozat is. Sok
programozo emiatt gyakran ahol egyetlen utasitast kell csak vegrehajtania ott
nem is alkalmaz blokkolast, es egeszen addig korrektul is mukodik a program,
amig nem modosit rajta (pl. meg egy utasitast hozzafuz a felteteles utasitas
igaz agaba). Ilyenkor csak nez, hogy vaj' miert nem azt csinalja a program, amit
szeretett volna. Gyorsan hozzafuz egy blokkolast, es ettol pedig mas blokkok
ertelmezese valtozik meg (lasd meg blokk kezdete es vege problema).
Nem hiszem, hogy a GOTO veszelyesebb, mint a szabadon hasznalhato blokkok...
Nyilvan konnyu lenne a szintaktikan valtoztatni, es akkor minden programozo ra
lenne kenyszeritve, hogy blokkokat hasznaljon minden esetben, azonban azon is
konnyu lenne valtoztatni, hogy csak blokkokon belulre engedjen ugorni a GOTO
utasiassal.
>Masreszt ha telepakoljuk gotoval a programot senki sem fogja erteni, meg a
Ezzel nem ertek egyet. Sokkal konyebben megertek egy ASM kodot, ami ugye tele
van "GOTO" utasitasokkal, mint egy OO szuperszervezesu csodaprogramot. Persze ez
agy kerdese is (van akinek az OO dolgok jobban fekszenek, van aki viszont
szeretne erteni is mitol megy a villamos). Magam nem tudok elvonatkoztatni a
geptol, es egy levegoben logo programot onmagaban elo dolognak tekinteni.
>Egyebkent meg megfelelo strukturalassal altalaban el lehet kerulni a
>hasznalatat.
Ez igaz -- de epp emiatt sokszor bonyolultabb is a program szerkezete, es hat
nyilvan lasabb is.
En inkabb azt mondanam, hogy a GOTO-nak megvan a helye, es ha okosan hasznalja
az ember, akkor nem lehet vele galibat okozni.
Remelem azt mondanom sem kell, hogy magam sem szoktam GOTO-t hasznalni (no
break-et, continue-t, exit-et meg return-t igen...), azonban csak amiatt mert
nehany akademikus ugy gondolja, hogy elmeletileg minden problemat le lehet irni
GOTO nelkul nem kellene megszuntetni a hasznalatanak lehetoseget. Azonkivul a
programozo lapantaknak is el kellene magyarazni mikor van ertelme, mikor
elkerulhetetlen (ertsd csak sokkal bonyolultabban lehetne strukturaltan leirni
ugyanazt) ill. mikor kerulendo stb az alkalmazasa.
Tamas
Tamas Rudnai / Sophos Plc
mailto:
http://www.sophos.com
|
+ - | Re: forditas (mind) |
VÁLASZ |
Feladó: (cikkei)
|
>Es te tudsz operandus nelkuli utasitasokat "letrehozni"? Meg ha tudnal is -
Letrehozni nem, hasznalni mar annal is inkabb. Gondolom tudsz ASM-ben
programozni, szerintem neked is eszedbe fog jutni egy par ilyen....
>Magyarul az utasitas az nem az, hogy "mov", hanem az hogy pl. "mov az, 0",
>"mov cx, ax", stb.
Ha igy veszed, akkor igazad van. Csakhogy a "mov" utasitasnak rengeteg gepi kod
felel meg, meg a mov ax, bx-nek is igy operandusokkal egyutt. Olvasd el az Intel
kezikonyvet! Ha ugy lenne, ahogy te mondod, akkor a mov cx, ax mas utasitas
lenne, mint a mov ax, 0. Szerintem csak mas a cel es a forras operandus, de
lehet, hogy tevedek...
>processzorokon egesz szamu bajtnyiak (magyarul: bitekben vett meretuk 8
>egesz szamu tobbszorose) azert IMHO egy kicsit durva...
Bocsanat, nem ez volt a megkozelites, hanem ez:
>>Szerintem inkabb pontosabb, ha a gepi kodot byte-ok
>>sorozatnak tekintjuk. Mivel minden utasitas hossza
>>egesz byte. Az utasitasok persze bitmezokbol epulnek fel.
Nem ugy tortent a kijelentes, hogy "minden utasitas beleertve operandusokat
prefixumokat byte-ok sorozatakent tarolodik".
>Szerintem a "byte" az mindig is 8 bit volt es lesz is... (Erdekes, hogy pl.
Igy tanitjak az oskolaban?
>az RFC-kben is megprobaljak kovetkezetesen az "octet" szot hasznalni, de
>azert csak becsuszik neha egy-egy "byte" is... Azert ez elarul valamit,
>nem?)
A rossz bevett szokasok. Nezz korul egy kicsit (tanulmanyozz regebbi gepeket is
pl.) es rajossz, hogy a byte = 8 bit kisse pontatlan, legfeljebb altalaban igaz
.
>Persze mondjuk nem hiszem, hogy sikerulne olyan autentikus szemelyiseget
>talalni, aki barmelyikunkek is _hitelt erdemloen_ igazat tudna adni e
>kerdesben. (Ez a "a byte hany bit" kerdes tipikusan olyan, mint a nyelv
>alakulasa: valojaban _nem_ a nyelveszek, hanem az emberek alakitjak es
>formaljak a nyelvet - a nyelveszek inkabb csak rogizitik a valtozasokat...)
Igen, epp emiatt hasznalja nehany felhasznalo a "flopitot" kifelyezest a floppy
targyas esete helyett, emiatt tarsitjak a "PC" betuosszetetelt az IBM-PC -vel es
emiatt gondoljak, hogy az "Intel processzor" kifejezes egyertelmuen behatarolja
az Intel 80x86 processzor csaladot. Nem kerem, ha altalanossagban beszelunk
valamirol, akkor pontosan fogalmazzunk -- pontatlanul fogalmazhatunk akkor, ha
egy adott kornyezetben (mindenki szamara vilagos, hogy melyik) hasznalunk
valamit. A "gepi kod" azonban nem hatarol be sem processzort sem pedig
platformot vagy miegyebet, tehat ez esetben a "byte" nem mondja meg hany bitrol
is van szo...
Irod, hogy kotozkodok -- eddig nem tettem, de ezzel az utolso bekezdessel mar
valoban ez volt a szandekom.
Tamas
Tamas Rudnai / Sophos Plc
mailto:
http://www.sophos.com
|
+ - | Re: Assembly (mind) |
VÁLASZ |
Feladó: (cikkei)
|
>Barmilyen programnyelvben lehet irni gepi
>vagy assembly kodot, ertelemezi a fordito?
>A C-be ugy tudom lehet.
Ezt forditoja valogatja. Az altalanos celu nyelvek (pl. Pascal, C) forditoi
altalaban megengedik, mig a specializaltaknal vagy csak linkelni lehet asm
beteteket, de maga a forraskodba irni nem (pl. Clipper) vagy egyaltalan nem
engedik meg ilyen bovitesek hasznalatat (pl. dBase)...
Gabor
|
+ - | Re: Soros port programozasa (mind) |
VÁLASZ |
Feladó: (cikkei)
|
>> Persze egyebkent tortenetesen egy jol megirt soros-port kezelonek az sem
>> okoz gondot, ha ugyanazt a megszakitast tobb adapter is hasznalja... (Ti.
az
>> IIR segitsegevel egyertelmuen azonosithato, hogy melyikuk valtotta is ki
>> valojaban az aktualist megszakitast...)
>
>Gondolom az IIR valami Interrupt-al kapcsolatos dolog, de pontosan mi?
>Es melyik IO cimen erheto el?
IIIR = Interrupt Identification Register es a [bazis + 2] porton keresztul
olvashato ki.
Gabor
|
+ - | Re: forditas (mind) |
VÁLASZ |
Feladó: (cikkei)
|
>>Szerintem inkabb pontosabb, ha a gepi kodot byte-ok
>>sorozatnak tekintjuk. Mivel minden utasitas hossza
>>egesz byte. Az utasitasok persze bitmezokbol epulnek fel.
>
>Ez nem minden processzoron igaz, pl. az Intel 80x86-osokon _nem_!
>Az i80x86-on vannak valoban 1 byte-os utasitasok, de vannak rovidebbek,
ahol --
>legtobbszor 3 biten -- az operandust is belekodoljak a byte-ba, mint
legkisebb
>cimezheto tarolo egyseg. De vannak 2 sot 3 byte-os utasitasok is,
pontosabban
>ott is mar 1 vagy 2 operandus bele van kodolva a byte-okba, tehat maga az
>utasitas rovidebb. Azutan mi van a prefixumokkal? Tudnek 4 KByte-os
utasitast i
Es te tudsz operandus nelkuli utasitasokat "letrehozni"? Meg ha tudnal is -
mit csinalnanak azok? Ugye semmit, mert nincs _mivel_ muveletet vegezni.
Magyarul az utasitas az nem az, hogy "mov", hanem az hogy pl. "mov az, 0",
"mov cx, ax", stb.
Tudom hogy jo kotozkodni meg szorszalhasogatni (en magam is gyakran
alkalmazom ;), de azert abba belekotni, hogy az utasitasok az x86-os
processzorokon egesz szamu bajtnyiak (magyarul: bitekben vett meretuk 8
egesz szamu tobbszorose) azert IMHO egy kicsit durva...
>csinalni, amit valoban a proci vegre is hajt, es igaz maga az utasitas
hossza
>nem valtozik, de ha a prefixumokat is az utasitas reszekent kezeljuk, akkor
4
>KByte-osnak is mondhatjuk azt az 'egy' utasitast...
>Szoval vagy kulonvalasztjuk az utasitast magat a prefixumoktol es az
>operandusoktol es akkor ilyen ertelemben nem beszelhetunk kiveletl nelkul
egesz
>byte-ra vegzodo utasitasokrol, vagy egybe vesszuk oket, akkor viszont
kilometer
>hosszu utasitasokrol kell beszelnunk...
Latom szereted az extremitasokat. Csak az a baj, hogy meg ez sem tamasztja
ala a mondandodat, mert ettol meg mindig pontosan bajthatarra esik az
utasitasok eleje/vege...
>Nyilvan persze a program -- gepi kod -- byte-ok sorozatakent (meg
pontosabban
>oktetek sorozatakent, ugyanis a byte nem feltetlen jelent 8 bitet)
jelenitheto
>meg legegyszerubben, mint a legkisebb cimezheto egysege a mai modern
>mikrogepeknek es a legtobb mini ill nagygepnek (nyilvan regebben voltak
masfajt
>a
>gepek is -- meg 9 bites szervezesuek is, de voltak decimalis gepek is a
>digitalisok helyett --, es az is nyilvanvalo, hogy lesznek kesobb
masmilyenek
>is, pl. 64 bites szervezesuek -- ki tudja?)
Szerintem a "byte" az mindig is 8 bit volt es lesz is... (Erdekes, hogy pl.
az RFC-kben is megprobaljak kovetkezetesen az "octet" szot hasznalni, de
azert csak becsuszik neha egy-egy "byte" is... Azert ez elarul valamit,
nem?)
Ami valoban nem egyertelmu, hogy hany bites, az a szo ("word"), mert ez
tenyleg a gep nativ, biten feluli legkisebb tarolasi egyseget jelenti, es
mint ilyen pontos jelentese nyilvan alapvetoen attol fugg, hogy milyen
kornyezetben, mivel kapcsolatban hasznaljuk.
Persze mondjuk nem hiszem, hogy sikerulne olyan autentikus szemelyiseget
talalni, aki barmelyikunkek is _hitelt erdemloen_ igazat tudna adni e
kerdesben. (Ez a "a byte hany bit" kerdes tipikusan olyan, mint a nyelv
alakulasa: valojaban _nem_ a nyelveszek, hanem az emberek alakitjak es
formaljak a nyelvet - a nyelveszek inkabb csak rogizitik a valtozasokat...)
Gabor
|
+ - | Re: pic (#2) <-- soros port programozas -->Mc (mind) |
VÁLASZ |
Feladó: (cikkei)
|
>> ui: amugy a megszakitasokat oda 'teszed' at, ahova csak
>> akarod... azaz... a pic felsetupolasaval meg kell hatarozni
>> az interrupt base vektort, ahova a pic majd az irq-kat fogja
>> jelezni... ennek igazan vedett modban van jelentosege, ahol
>> az int 7 nel meg javaban exceptionok vannak....
>
>Errol tudnal adni reszletes informaciot? (Ez volt nekem mindig a furcsa,
>hogy vedett modban hogy nem akadnak ossze az exception-ok az IRQ-kal ...
>)
Elnezest, hogy a megszolitott helyett valaszolok, de a koz erdekeben
teszem.. ;)
;====================================
; Setup8259 -- Sets up interrupt controllers for modified IRQ vectors
;
; In : BL -- new low (0-7) vector base #
; BH -- new hight (8-15) vektor base #
;====================================
PROC Setup8259
mov al,11h
out 20h,al
jmp short $+2
mov al,bl
out 21h,al
jmp short $+2
mov al,4h
out 21h,al
jmp short $+2
mov al,1h
out 21h,al
jmp short $+2
mov al,11h
out 0a0h,al
jmp short $+2
mov al,bh
out 0a1h,al
jmp short $+2
mov al,2h
out 0a1h,al
jmp short $+2
mov al,1h
out 0a1h,al
ret
ENDP Setup8259
Gabor
|
+ - | Re: Windows task leloves (mind) |
VÁLASZ |
Feladó: (cikkei)
|
>Borland C++-t es C Builder-t hasznalok. A forditast jelentosen
>lelassitja a futo VirusScan (VShield) task. Azt szeretnem, ha a
>forditokat inditom az ikonjukkal, akkor az onnan indithato batch
>file zarja be a futo VirusScan, vagy mas task-ot.
>Hogyan kell ezt megcsinalni?
Elso korben probald meg az ablakot megtalalni a FindWindow()-val, aztan egy
SendMessage(,WM_CLOSE,,)-zal becsukni. Ha nem hallgat a szep szora, akkor
durvabb dolgokhoz kell folyamodni: le kell kerdezni az ablakhoz tartozo
ProcessID-t a GetWindowThreadProcessId()-vel, ez alapjan kell nyitni hozza
egy handle-t az OpenProcess()-szel, majd a kapott azonositot felhasznalva
egyszeruen ki kell loni a TerminateProcess()-szel...
Gabor
|
+ - | Re: CHM (mind) |
VÁLASZ |
Feladó: (cikkei)
|
>>Hogyan lehet chm kiterjesztesu file-t eloallitani egy HTML oldalbol ?
>>Feltetelezem a chm a compilled html roviditese, vagy valami ehhez
>>hasonlot jelenthet.
>
>Es ha meg azt is el tudna valaki mondani, hogy egy HTML-t miert kell
>_compilalni_?
Gondolom azert, mert egy binaris formatum mindig tomorebb, mint szoveges
(ember altal konnyen olvashatobb) megfeleloje... Raadasul a kisebb merettel
ugye gyorsabb feldolgozasi sebesseg is egyutt jar, amibol egyertelmuen
kovetkezik a dolog masik elonye...
Gabor
|
+ - | Delphi scanner komponens (mind) |
VÁLASZ |
Feladó: (cikkei)
|
>Mit tudtok javasolni, melyik jo, melyik nem, es hogyan
juthatnek
>hozza? Netcim vagy emiles felajanlas is megfelel. Mivel
itthonrol
>szorfozom, igy meretmegjelolest is szivesen fogadok!
www.twain.org
Remelem segitettem...
Veres Sandor
|
+ - | HELP - Programozasi fogalmak (mind) |
VÁLASZ |
Feladó: (cikkei)
|
>Ilyen progit kellene irni, ami ilyet tud:
> -dinamikus adatszerkezet
> -pointerek
> -láncolt lista
>
>A kozepso OK, de a masik ketto nem.....
Ezeket a progi nem 'tudja', hanem hasznalja, mert ezek
adatszerkezeti
fogalmak, elemek:
dinamikus adatszerkezet: a program futasa kozben
letrejovo/alakulo
adatszerkezet. Pl. a lancolt lista ilyen.
pointerek: a memoria adott helyere mutato mutatok (vagy hogy
lehetne
jobban leirni). A dinamikus adatszerkezet felepitesehez
nelkulozhetetlenek,
mert ezek kapcsoljak ossze a szerkezet egyes elemeit.
lancolt lista: Az adatelem tartalmaz a konkret adaton kivul
mutatok(at) is,
amelyek a kovetkezo (es/vagy elozo) elemre mutatnak. A lista
kezelese
ezen mutatok alapjan tortenik. Pl. beszuras eseten
letrehozunk egy uj elemet,
betoltjuk az adatokat, majd a megfelelo lista-helyen az
elozo elem kovetkezo
adatot mutato pointeret elmentjuk es feltoltjuk az uj
elemre, az uj elem
kovetkezo adatot mutato pointeret az elozoleg elmentett
pointerre allitjuk.
Ezzel beszurtuk az elemet a listaba.
A listak kezelesehez (tkp. barmilyen dinamikus szerkezethez)
kell egy
un. fej, ami az adatszerkezet elso elemet mutatja.
>Ja es valaki tudja ertelmezni a kovcsi forrast. Sima text
filet olvas ki/be,
>de mi ez a sok pointer??
>
> assign(sz,'d:\prg\pascal\sajat\libra');
> reset(sz);
> i:=0;
> new(fej);
> fej^.eloz:=nil;
> fej^.kov:=nil;
> fej^.adat.peldsz:=0;
> akt:=fej;
> while not eof(sz) do
Megnyitja az allomanyt. Letrehozza az uj elemet (new),
torli az elozo, kovetkezo
mutatokat (=nil). Utanna csinal valamit az allomany vegeig
(while).
>A valtozok pedig:
> sz: text;
> i: integer;
> seged: konyvt;
> vegjel: string[3];
> ch: char;
> akt: mut;
sz: az allomany, akt: aktualis elem mutatoja
>Illetve:
> konyvt=record
> cim: cimstr;
> szerzo: str30;
> kvaros: str20;
> kiado: str30;
> kev: integer;
> peldsz: longint;
> oldal: integer;
> raktjel:string[10];
> beszer:record
> ev: integer;
> ar: longint;
> db: integer;
> end;
> kotes: kotestip;
> kolido: byte;
> end;
> mut=^elemt;
> elemt=record
> adat: konyv
> eloz,kov: mut;
> end;
Biztos jol irtad? KONYV lenne az elso rekord, vagy adat:
KONYVT?
Elemt tartalmazza az adatot, eloz, kov az elozo ill.
kovetkezore mutatnak.
Tehat egy ketiranyu kapcsolt lista (elore es hatra is
kezelheto).
>Valaki erti, illetve ha valakinek gyanus, hogy erti, akkor
irjon nekem es
>elkuldom a teljes PAS-t.....
>EZER koszonot, nagyon fontos...
Elobb probald magad megerteni, ha elakadsz, akkor szolj!
Bonyolultabb listanal (pl. binaris fa) celszeru rajzolni a
kapcsolatokat.
Veres Sandor
|
+ - | Miert nem helyes a GOTO? (mind) |
VÁLASZ |
Feladó: (cikkei)
|
> A GOTO a regebbi nyelvekben jatszott jelentosebb szerepet, e nelkul nem
> lehetett programozni.
> Mara viszont a programozas rakos sejtjeve valt, amit minel elobb ki kell
> vagni. A strukturalt programozassal nehezen fer ossze. A ciklusokbol,
> programegysegekbol valo ugralgatasnak a lehetosege rengeteg
> hibalehetoseget rejt magaban, ezaltal kevesbe stabil progikat irhatunk.
> Masreszt ha telepakoljuk gotoval a programot senki sem fogja erteni, meg a
> programozo sem. Kovetkezeskeppen ha modositani kellene, akkor lehet, hogy
> egyszerubb ujra megirni (ha tanult az esetbol, legkozelebb mar goto nelkul
> irja).... Talan nem veletlen, hogy a JAVA-ban is csak foglalt szo a goto
> es nincs implementalva.
Egyetertek a fentiekkel, amennyiben az ember TANUL programozni. Amikor
mar tudja, hogy mit hogyan, akkor neha rakenyszerul.
Leirom, hogy en mire hasznalom a goto-t C-ben, eppen java-s gyakorlat
utan:
- Tobb egymasbaagyazott ciklusbol valo kiugrasra. (java-ban ezt
lehet a break utasitassal, C-ben nem, tehat marad a goto )
Ha nem goto-t hasznalnek, akkor a kiugrasi feltetelt az _osszes_
ciklus feltetelebe bele kellene tenni, ami hosszabb kodot es
lassabb programot jelentene.
- kivetelkezelesre, szinten mert a C-ben nincs. Pl.:
if( !(akarmi = calloc(1, sizeof(akarmiType)) )) {
goto out_of_memory;
}
/* ... */
return MINDEN_OK;
out_of_memory:
OutOfMemory_Message();
return CIKI_VAN;
Ha itt nem hasznalnek goto-t akkor csak a program olvashatosaga
romlana rohamosan, kulonosen tobb kivetelelofordulas es/vagy
kiveteltipus eseten.
Ki mire hasznalja meg a goto-t?
Udv
Szabolcs
|
+ - | Re: Goto? (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Sziasztok,
Biidzsii:
>A GOTO a regebbi nyelvekben jatszott jelentosebb szerepet, e nelkul nem
>lehetett programozni.
>Mara viszont a programozas rakos sejtjeve valt, amit minel elobb ki kell
>vagni. A strukturalt programozassal nehezen fer ossze.
Nos ezzel igy nem ertek egyet.
Egy program nem at goto -tol lesz strukturalatlan, hanem attol, hogy
strukturalatlanul irjak meg. Goto nelkul is lehet strukturalatlan
prgramot irni, s Goto-val is lehet strukturalt programot irni - csak
nehezebb, ennyi az egesz :)
Sziasztok,
Juan
|
+ - | Re: Assembly (mind) |
VÁLASZ |
Feladó: (cikkei)
|
On 30 Nov 99 at 11:59, wrote:
> Barmilyen programnyelvben lehet irni gepi
> vagy assembly kodot, ertelemezi a fordito?
> A C-be ugy tudom lehet.
Barmilyen nyelven nem lehet. Elvileg C-ben sem lehet, legalabbis az
ANSI C nem definial ra standard megoldast tudtommal, de valoszinu
minden C fordito megengedi ezt valahogy, csak epp meg ugyanazon a
processzoron sem lesz ettol hordozhato a forras.
István
-- Istvan Marosi -- http://www.sch.bme.hu/~marosi --
-- Recosoft Ltd. -- mailto: --
|
+ - | Re: Miert nem helyes a GOTO? (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Ugy tudom, hogy a strukturalt programozas szuletesenel ket okbol
erveltek sokan a goto ellen: Az egyik, amiket mar masok is irtak itt,
hogy atlathatatlanna teheti a programot, ezzel hibalehetosegeket hoz
be. A masik, hogy egy goto nelkuli strukturalt programot _elvileg_
jobban lehet a forditonak optimalizalni, mintha goto is lenne benne.
Gyakorlatilag viszont vannak olyan esetek, amikor ugy egyszerubb a
program, ha ugrik az ember neha-neha. Masreszt amikor nagyon a gotora
szorul az ember, akkor goto nelkul bonyolultabb a lenne a program,
amit barmilyen jo optimalizalo se tud olyanra optimakolni, mint ha
benne van a goto.
István
-- Istvan Marosi -- http://www.sch.bme.hu/~marosi --
-- Recosoft Ltd. -- mailto: --
|
+ - | Re: Felbontas csokkentes (mind) |
VÁLASZ |
Feladó: (cikkei)
|
On 26 Nov 99 at 16:35, wrote:
> Adottak x felbontasu fileok amiknek a afelbontasat kellene
> cokkentenem (persze nem felezesrol,negyedelesrol van szo),de ezt
> valamilyen ertelmes modon aminek az eredmenye jo minosgu marad
> (minel kevesbe legyen reces, ha valahogy a sima minden x edik pixel
> kidobalasanal jobb modon).
Nem irtal sok reszletet, de feltetelezem, hogy 1 bit/pixel-es (1 bpp)
keprol van szo, es csak 'kicsit' akarod a felbontast csokkenteni.
Ilyenkor a legnehezebb a helyzet, mert nincs sok olyan extra
informacio a kepben, amibol a receket el lehetne hagyni.
Valoszinu nem nagyon ertheto a dolog, vegyunk peldakent egy masik
esetet, ahol konnyebb a helyzet: Az eredeti kep szurke (N bpp),
amibol szintre vagassal jott letre az 1 bpp kep, aminek a felbontasat
kell csokkenteni. Ilyenkor letre lehet hozni szep kepet ugy, hogy
eloszor visszalepunk a szurke kepre, annak a felbontasat csokkentjuk,
es aztan azt a kepet vagjuk szintre. Az extra informacio az, hogy a
szurke kep felbontascsokkentesenel nem ugy jarunk el, hogy minden
x-edig pixelt elhagyjuk, hanem ugy, hogy az egymas utani pixeleket az
n*(x-1)/x koordinatabol vesszuk, es a tort poziciok szurkesegi
erteket linearis interpolacioval becsuljuk meg.
Masik egyszerubb eset: 1 bpp az eredeti kep, viszont nagyobb merteku
felbontascsokkentest csinalunk: pl. x pixelbol csak 1 pixel marad
meg. Ilyenkor megtehetjuk azt, hogy az x*x meretu negyzetekben
eloallitunk egy mesterseges szurke erteket a benne levo fekete
pixelek szama alapjan, igy eloall egy csokkentett felbontasu szurke
kep, amit aztan szintre vagva eleg szep 1bpp kep lesz. Itt az extra
informacio az, hogy sok pixelt hagysz el a kepbol.
Ha nem tudsz szurke kepbol kiindulni, es a felbontast is csak kicsit
csokkented, akkor max. annyit tehetsz, hogy a fentebbi elso modszert
alkalmazod ugy, mintha a 0-as pixelek 0, az 1-esek 255-os szurke
erteknek felelnenek meg, es ezek kozott interpolalsz, vegul kb.
128-cal vagsz szintre. Nem probaltam meg ilyet, szoval nem tudom,
hogy mennyivel lesz igy szebb a kep annal, mintha siman kihagynal
minden x-edik pixelt, valoszinuleg egy kicsivel azert jobb igy.
Lehet meg olyan buveszkedest is csinalni, hogy amikor az 1bpp-bol
8bpp-t csinalsz, akkor nem 0 ill. 255 ertekeket helyettesitesz be,
hanem a szomszed pixelek erteket is figyelembe veszed ugy, hogy az
aktualis pixelt 128-as sullyal, a 8 szomszedot meg egyenkent
kevesebb, mint 16-os sullyal veszed figyelembe (tehat az osszes
szomszed egyutt kevesebb, mint 128-as sulyt tud hozzatenni). Ezek a
sulyertekek biztositjak, hogy ha az igy eloallo mesterseges szurke
kepet 128-as kuszobbel szintre vagnad, akkor tuti az eredeti 1bpp
kepet kapnad vissza, szoval a szurke kep megfelel az eredeti
fekete-fehernek. Ezen a szurke kepen az interpolacio aztan valoszinu
egyenletesebb ertekeket eredmenyez...
Jo kiserletezest. Ha jutsz valamire, ird meg nekem, erdekel :)
István
-- Istvan Marosi -- http://www.sch.bme.hu/~marosi --
-- Recosoft Ltd. -- mailto: --
|
+ - | PIC prg + forditas (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Sziasztok!
>Errol tudnal adni reszletes informaciot? (Ez volt nekem mindig a furcsa,
>hogy vedett modban hogy nem akadnak ossze az exception-ok az IRQ-kal ...
At kell programozni a megsz. vezerlot. A lenyeg, hogy at kell helyezni az IRQ-k
at
olyan teruletre, amely nem fedi az exception-oket. A kov. kodreszlet az IRQ-kat
a 20h-30h teruletre teszi ra. Tehat IRQ0 - az 20h megszakitas lesz es igy tova
bb.
Remelem tudod hasznalni az infot. (Arra azert figyelj, hogy az IDT-t is be kell
allitani, vagy
a megsz. tablazatot)
cli ; megszakit sok letilt sa
mov dx,2028h ; IRQ 20h-30h kozott, ezt kell atirni, h
a mashova akarod
mov al,10001b ; a 28h a 20h-30h fele akar lenni
out 20h,al ; A tobbi mar csak a PIC piszkalasa
mov al,dh
out 21h,al
mov al,100b
out 21h,al
mov al,1
out 21h,al
mov al,10001b
out 0a0h,al
mov al,dl
out 0a1h,al
mov al,10b
out 0a1h,al
mov al,1
out 0a1h,al
sti ; megszakitasok engedelyezese
///////////////////////////////////////////////////////////////////////////////
/////////////////
FORDITAS:
>>Szerintem inkabb pontosabb, ha a gepi kodot byte-ok
>>sorozatnak tekintjuk. Mivel minden utasitas hossza
>>egesz byte. Az utasitasok persze bitmezokbol epulnek fel.
>Ez nem minden processzoron igaz, pl. az Intel 80x86-osokon _nem_!
> stb....
Ez erdekes, legyszives irj mar le egy darab olyan 80x86-os utasitast ami nem
egesz szamu byte-bol all. Egyebeknt pedig gondolom tudod egy utasitasba azert
sok minden bele lehet kodolva de attol az meg egy utasitas marad.
Masreszt az Intel doksikban a prefixeket az utasitassal egybe kezelik. Eppen ezert
irjak azt a General Protection-nél, hogy kiválthatja az utasitashossz 15 byte-nyi
korlatjanak atlepese. ( Es itt bele ertik a prefixet az utasitashosszba.) Ugyhogy
15 byte-nal hosszabb utasitast szerintem nem tudsz futtatni, vagy ha igen
azt is mutas egyet. Kuldhetnel egy 4KB utasitast is, kivancsi vagyok, hogy megy
a gepemen.
Mellesleg a 4KB nem byte-ok sorozata?
Ugyhogy szerintem minden egyes utasitas amit a 80x86 vegrehajt, az valahany byte.
bye...
--
> -----------------------------------------------------------------
Bojcan Tamas Phone: +36-30-9813-349
E-mail: ||
Web: www.cab.u-szeged.hu/~h836855
|
+ - | T3E (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Akiket erdekelnek a programozasi, optimalizalasi csemegek,
tudom ajanlani a CRAY T3E-re vonatkozo segedletet, ami a
Silicon Graphics honlapjan van. Ha valaki keri, elkuldom (82kB,
rar, pdf).
blabla
|
+ - | Re: *** HIX CODER *** #658 (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Interrupt Identifier Register,
Port Address + 2
Interrupt Control Functions:
Highest: 00000110: Receiver Line Status
00000100: Received Data Available
Lowest: 00000010: Transmitter Holding Register Empty
Feri
-----Eredeti üzenet-----
|
+ - | Re: Soros port programozasa (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Hello!
> Persze egyebkent tortenetesen egy jol megirt soros-port kezelonek
az sem
> okoz gondot, ha ugyanazt a megszakitast tobb adapter is
hasznalja... (Ti. az
> IIR segitsegevel egyertelmuen azonosithato, hogy melyikuk valtotta
is ki
> valojaban az aktualist megszakitast...)
Gondolom az IIR valami Interrupt-al kapcsolatos dolog, de pontosan
mi?
Es melyik IO cimen erheto el?
Udv
--
Tamas Selmeci / TOR][UM
mailto:
F0 0F C7 C8 rulez!
|
+ - | Visual C++ COM tanfolyam (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Hello,
Aki szeretne VC++ 6 COM-fejlesztoi tanf-ra menni, az szoljon!
Surgos lenne, jovo januarig kellene min. 2-3 ember, aki jelentkezik!!!
A tanf. ara: 125.000 Ft, ideje: januar 17-21.
Ha tudsz ismerost aki jonne, akkor neki is szolj legyszi!
AZ IS JO, HA VALAKINEK MEGVAN A TANF. ANYAGA!
Koszi
Liptak Oliver
|
+ - | CAB-error (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Van valaki aki már találkozott ezzel a
hibaüzenettel, hogy CAB error?
Mi okozhatja?
|
+ - | Re: CHM (mind) |
VÁLASZ |
Feladó: (cikkei)
|
>>Hogyan lehet chm kiterjesztesu file-t eloallitani egy HTML oldalbol ?
>>Feltetelezem a chm a compilled html roviditese, vagy valami ehhez
>>hasonlot jelenthet.
>Es ha meg azt is el tudna valaki mondani, hogy egy HTML-t miert kell
>_compilalni_?
Hat, ha jol tudom csak azert, hogy egy darab help fileba legyen az
egesz,
es ne sok kulon html-be. Egyebkent pedig nem tudom, hogy miert
keresel ertelmet abban amit az M$ csinal?
Udv:
Ebux
Eberhardt Gergely
ICQ UIN: 22870683
http://www.vbuster.hu mailto:
|
|