Hali
Van egy progi, amelyik nagy matrixokkal ill. vektorokkal (ca. 2Mb) dolgozik.
Linux alatt nincs vele semmi gond, de at kellett irni dos-ra es itt mar
nem tud ilyen nagy memoriat allokalni a matixnak ill vektornak, pedig lenne
boven. Dosemu alatt meg sikerul is az allokacio neki ill. lefut
a program, de kilepeskor nem tudja a commamd.comot betolteni system halted
stb. Rendes dos eseten mar program futas kozben sem sikerul a memoria
allokacio es jon a  sokasos system halted. A program huge modelben lett
forditva, es tudomasom szerint menni kellene ilyen aprosagoknak is dos
alatt.
Mit felejtettem el beallitani ill. mi lenne a gyogyir?
koszi a segitseget
pali

Hali mindenki !

Olvasgattam a *** HIX CODER *** #69 -et .
Miert kell bantani szegeny DN-t ??????
Tudomasom szerint :))) a DN-be a Direct Disk Acces
kikapcsolhato !!!!!  Ezutan felteszem a rendes 21h-s
megszakitassal kezeli a disket.  :))) , es az emlitett
TSR mar muxik is...

Ha hulyeseget irtam, akkor U:SSETEK !!!!!!
:)))

Pati

>Akkor minek mind cikizik az
>embert hujesegekkel (gondolok itt a tanitto-bacsikra elsosorban)?
Alapvetoen a cel egyfajta gondolkodasmod kialakitasa, hogy
ne csak a mar meglevo reszmegoldasokbol tudjal osszeallitani egy kesz
dolgot, hanem hogy elore nem vart problemakat is hatekonyan meg
tudjal oldani. Mellesleg pedig altalaban az ilyen feladatok arra
probalnak raszoktatni, hogy ha szukseges, akkor meg az egyes
reszfeladatokat akar a legoptimalisabb modon tudd megoldani.

>Olvastam, a megirt szoftwerek 98% tradicionalis modon mindenfele
>ravasz trukkok nelkuli modon van megirva.
Na igen, ezert aztan nem is kell csodalkozni, ha folyton sok megabyte-os
lassan futo programokkal akadsz ossze. Nagyon elterjedt hit, hogy
a mai fordito programok ugyis nagyon jol optimalizalnak, es ezert
felesleges optimalizalasra sok idot pocsekolni. Ez reszben igaz,
de csak reszben. Ugyanis ahhoz, hogy tenyleg optimalis kodot
generaljon a fordito, ahhoz meglehetosen jol kell ismerned, hogy
mit hogyan is fordit le, es ezen ismeret felhasznalasaval kell
megirnod a forrasodat.
Hadd meseljek el ket a valo eletbol vett peldat, amit nem en kovettem
el, de utana nekem kellett vele foglalkozni.
Mindket pelda C++. Az elso eset egy halmaz tipus megvalositasa korul
bonyolodott. Maga a struktura eleg nagy volt, volt benne egy 1000-es
meretu tomb. Egy ido utan ez keves lett igy fel lett huzva 10000-re.
Ennek az lett az eredmenye, hogy a program futasi ideje majdnem 10-szer
lassabb lett. A gond onnan jott, hogy egy fuggvenyben lokalis valtozokent
szerepelt ket ilyen osztaly, es mivel a C++ alapban egy default ertekkel
inicializalja az osztalyt, ezert minden alkalommal amikor meghivodott
a fuggveny elvegzett egy meglehetosen hosszu ideig tarto inicializalast.
A valtozok globalissa tetele vegul is megoldotta a problemat.
A masik eset pedig egy 3-dimenzios vector osztaly korul alakult ki.
Tulajdonkeppen csak annyi volt, hogy maguk a vector muveletek operator
atdefinialassal lettek megcsinalva. Ez nagyon jo es nagyon szep es mukodik
is, de kivancsi lettem hogy megis mit fordit belole a fordito.
Nagyon meglepodtem, amikor azt tapasztaltam, hogy egy sima vector osszeadasbol
generalt vagy 30 assembly sort es mindezt teljes optimalizalas mellett.
Gondoltam megnezem mit fordit akkor, ha ez szepen kifejtve leirom es
ahogy vartam mindjart mar csak ugy 10 sor korul volt.
A kodot vegignezve vegulis ertheto volt, hogy miert is volt 30 sor
az elso valtozat. A lenyeg az, hogy mivel a kifejezes eredmenye egy class
volt, ezert eloszor letrehozott, egy lokalis class valtozot a stacken
ezt felinicializalta, majd ide kiertekelte a kifejezest, majd innen
az erdemenyt szepen atmasolta, a cel valtozoba.
Vegulis ugyanazt a feladatot megoldotta 3-szor annyi utasitassal (orajel)
es meg felesleges memoria muveleteket is vegezett (sok orajel!).
Mivel a program 90%-a ilyen muveletek kiertekelesebol allt es a feladat
sebesseg kritikus volt, lehetett kidobni az egeszet.

Vegulis csak oda akarok kilyukadni, hogy az optimalizalas tud lenyeges
lenni, es nem csak assembly szinten, hanem magasabb szinten (C,C++) is
van ertelme, es amikor ilyen _mesterseges problemakkal_ talalkozol,
akkor igazandibol ennek a szemleletnek az elultetese a cel.
Mellesleg kesobb siman talalkozhatsz olyan problemaval, ahol egy
ilyen most meg _mestersegesnek_ latszo feladatot kell megoldani.

Biczo Tibor

Halika minden codernek!

  Bar nem tartom magam codernek, azert feljelentkeztem erre
a listara (is) :) Manapsag ugyanis az is coder(nek tartja magat),
aki tudja, mijaza INT, de vhogy a FORra, meg a IFre nem is
emlekszik... 

  Akkor valasz Moszinak es a tobbieknek:

Moszi irta:
>  Gondolom kozuletek sokan ismerik a Dos Navigatort.
> Nos a helyzet az, hogy irtam egy programot amely bizonyos konyvtarakbol
> nem enged torolni. Ezt a 21h megszakitas atirasaval ertem el es
> figyeltem a torlo funkciokat es ha az en konyvtarambol probalt torolni
> akkor hibat teritettem vissza. A NAGY baj az, hogy a Dos Navigatornak
> van egy olyan funkcioja amely kikuszoboli hogy ne az OS fuggvenyeivel
> kezelje a lemezt. Ilyenkor persze a programom az bukik.
>   Nos a kerdes : mi erre a megoldas ?

  A legegyszerubb megoldas, ha hagyod a francba az egesz 13 mexakot,
s meg jobban ratelepedsz a 21-ra. Mondjuk ugy, hogy a DIR se
lassa a konyvtarat + a DN se. Ez a 11, 12, 4e, 4f mexakok.
Van egy hatrany is, a konyvtarad abszolut nem lesz lathato,
de a torlesi tilalmad igy legalabb eletben marad, s meg debugolni
se kell :)
Ez a legjobb modi arra, hogy ne turkaljanak bele a konyvtaradba.
Azt viszont meg kell oldanod, hogy TE (pl. egy jelszo ismereteben)
belekukanthass a dolgaidba. Irj egy .SYS filet, rakd be a config.sysbe
+ egy-ket segedprogram, es kesz is :) Nekem igy mukszik.
  A vegere meg maradt egy rem: minden szam hexa :o
Meg meg egy: ha a 11-12 rutinokat (ezt hasznalja a dos DIRje)
figyeled, akkor a CHKDSK hibas faljnak tekinti, s szepen
redukalja a meretet 0-ra :(
A masik kettot hasznaljak az NC, DN, VC, de meg a windows
filekezeloje is :)
  Nu mara ennyit.

!!!HELP!!!

  Mindenfajta tomorito-algoritmus erdekel. Veszteseges IS !

Bye,
     Tooth 'Gabry' Gaabor
     mailto:
     post:H-4001 Debrecen P.O. Box 515, HUNGARY

--
E'rdemes hu:lye'nek lenni, mert mindig az okos enged.