1. |
sysinfo+ertelmetlen feladatok (mind) |
19 sor |
(cikkei) |
2. |
re: mesterseges problemak (mind) |
34 sor |
(cikkei) |
3. |
3d algoritmus (mind) |
9 sor |
(cikkei) |
4. |
windows-os exe meghivasa VC++ 5.0-val (mind) |
16 sor |
(cikkei) |
5. |
Prim program WEB publikalas (mind) |
25 sor |
(cikkei) |
6. |
Re: primszamolas ( 33 sor ) (mind) |
12 sor |
(cikkei) |
7. |
Re: Valtozocsere (mind) |
12 sor |
(cikkei) |
8. |
Re: mesterseges problemak (mind) |
10 sor |
(cikkei) |
9. |
Re: Dos navig+int 13h (fwd) (mind) |
30 sor |
(cikkei) |
10. |
++DN (mind) |
22 sor |
(cikkei) |
11. |
DOS NAVIGATOR (mind) |
14 sor |
(cikkei) |
12. |
Re: adatok az exe-ben (mind) |
30 sor |
(cikkei) |
13. |
Re: mesterseges problemak (mind) |
87 sor |
(cikkei) |
14. |
Re: nagymatrix (memoria allokacio)B (mind) |
29 sor |
(cikkei) |
|
+ - | sysinfo+ertelmetlen feladatok (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Szervusztok. Egyszer mar megkerdeztem, akkor nem jott valasz, es hat azota
sok ido eltelt....
Szoval: az volna a kerdesem, hogy tudtok-e olyan API-kat, vagy vegso esetben
Delphi komponenseket, amelyekkel a BIOS-infokat lehet lekerdezni. Konkretan:
CPU
tipus, (de azt is, hogy pl. MMX-e), IRQ foglaltság, ilyenek.
A masik problema: van ket GIF-eket kezelo komponensem, de
az egyik nem tudja a transparent layert kezeni, a masik viszont
annyira tudja, hogyha mozgatom a kepet, akkor formig atlatszo lesz. Vagyis
ha egy GIF felett mozgatom, azt is atlatszova teszi.
Tudtok valami megoldast erre?
Segitsegeteket koszonom, elore is
Szadai Karoly
Ui.: Nem akarom tulreagalni a mesterseges problemak ugyet, de:
1. En a Hanoi Tornyai problemaval tanultam a rekurziot, annak sem volt sok
ertelme, de nekem nagyon tetszett megis.
2. Talan nem csusztatas: a tulipant sem az ertelme miatt szeretjuk - mar ha
van neki egyaltalan. Vagyis: egy algoritmus is tud szep lenni.
|
+ - | re: mesterseges problemak (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Hi!
>Vajon miert van az, hogy olyan gyakran, az itt (de nem csak az itt)
>kozolt programozasi problemak annyira a valosagtol elrugaszkodottnak
>latszanak?
Mert akik ezzel foglalkoznak, azokba szorult nemi fanatizmus a
programozas teren.
>A peldakra gondolok amelyekben egy programot kell ugy megirni hogy ne
>hasznaljunk benne valamilyen ervenyes konstrukciot
Agytorna. Kihivas. Sportertek.
>( ez pont olyan mintha valaki azt mondana meseld el a kedvenc konyved
>tartalmat de ugy hogy az o es z betuket soha se hasznald)
Pontosan. Ezt szeretik benne sokan. Milyen uncsi lenne mindig mindenet a
hagyomanyos modszerekkel megoldani. Az ilyen orokos probalkozasok, uj
megoldasok keresese viszi tovabb a tudomanyt is.
>Nem igazan tudok elkepzelni egy progit melyben esszencialis volna egy
>primszamrol tudni hogy prim-e.
Nem is ez a lenyeg, hanem az, hogy gondolkodsz rajta. Ugyanazt a csirket
vagy mit sokfelekepp meg lehet nyuzni, de hogy lehet a legegyszerubben
es a leggyorsabban?
>C konyvek tucatjai a "Rekurzio" cimu fejezetnel faktorialis szamolas
>hasznalataval abrazoljak a rekurziv fuggvenymeghivast
Ez tenyleg eleg elborult, mert a rekurziv dolgok piszok lassuak.
>rendszerosszeesest ha nem vigyazunk.
Rakerdezhetek? Windows?
>Akkor minek mind cikizik az embert hujesegekkel (gondolok itt a
tanitto->bacsikra elsosorban)?
Ezert kapjak a penzuket. Mert lehetne programozas oran Quake-ezni is,
csak akkor most jatszani vagy programozni akarsz? Meg azert a
tanarbacsik (altalaban) megtanitjak a programozasi teteleket is.
udv
Arp
or
|
+ - | 3d algoritmus (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Sziasztok!
Szuksegem lenne egy olyan algoritmusra, ami megjelenit 3D-ben egy
gömböt.
Ha van valakinek ilyen, sokat segitene vele. Koszi.
Zida - Bencs Zoltan
UIN: 7467912
mailto:
|
+ - | windows-os exe meghivasa VC++ 5.0-val (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Sziasztok!
Van egy win-es exe-m, amibol ciklikusan meg akarok hivni egy masik
win-es exe-t, aminek at kell adnom par parametert.
Probaltam a system()-mel. Ezzel ment, csak furan viselkedett es
dos-os ablakban inditotta el az uj exe-t.
Probaltam a _spawnlp()-el, de nem sikerult.
Ezenkivul talaltam meg CreateThread()-et egy pelda fileben, de
nem tudom, hogy jo-e ez nekem.
Van tippetek?
Pisti
|
+ - | Prim program WEB publikalas (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Hi Coders!
Part 1:
A HIX CODER #67-es szamaban igertem, hogy DiCE kollega
HomePage-re felteszem a prim programot + forrast.
Ezt megtettem, a cime:
http://148.6.26.205/dice/letoltes.htm
Minden kedves codernak felhivom a figyelmet
a kodban szereplo egyetlen!!! osztasra. :)))
A program a longint tartomanyra mukodik, idomerovel ellatott,
nem bugos, gyors, optimalizalt :)))
Az alapertek (100%) -1 to 1millio Cyrix 16.6 msec,
ehez merjetek :)))
Ha valakinek esetleg gyorsabb, pontosabb progija
lenne kuldje el nekem (thanx**n).
Ha kedvet erez a Lista akkor atirjuk n bitesre :)))
(sokan) es termeszetesen publikaljuk :)))
udv: XiX
-=- -=-
-=- Minden masodik szavam hazugsag -=-
|
+ - | Re: primszamolas ( 33 sor ) (mind) |
VÁLASZ |
Feladó: (cikkei)
|
> Az pedig, hogy a szam prim-e, viszonylag egyszeru ellenorizni,
> pl. a kis Fermat tetellel(*):
>
> Ha p prim es (a,p) = 1 akkor a^p = a (mod p)
Nem kotozkodes gyanant irok, de elkepzelheto, hogy nem mindenki tanult
szamelmeletet, aki a codert olvassa. Az elobbi allitas nem igazan allja
meg a helyet: a^p ugyanis nem egyenlo a (mod p) eseten. CSAK KONGRUENS! Es
a ketto eg es fold!
Zsozso
|
+ - | Re: Valtozocsere (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Sziasztok!
> Hmm, nem is gondoltam vegig hirtelen, az osszeadas-kivonas
> tulcsordulas eseten is jo??
>
Erre nem gondoltam, amikor megirtam. Most kiprobaltam maxlongint-el es
maxlongint-10 -el, es furcsamod korrekt eredmenyek jottek ki. Sot, meg
az extended tipusnal is minden gond nelkul felcserelt ket 20 jegyu
szamot. Szoval mukodik.
Gyongyosi Peter
|
+ - | Re: mesterseges problemak (mind) |
VÁLASZ |
Feladó: (cikkei)
|
>Akkor minek mind cikizik az
>embert hujesegekkel (gondolok itt a tanitto-bacsikra elsosorban)?
Anyukam meselte, hogy amikor ok vegeztek a kozepiskolat (60-as evek
kozepe), akkor csak ugy mellekesen megemlitettek, hogy van a decimalison
kivul mas szamrendszer is (de mivel gyakorlati jelentosege egyenlo a
nullaval, nem is foglalkoztak vele).
Ezek utan ha lennel szives meghatarozni, hogy mit ertesz "mesterseges
probleman" ?
A'kos
|
+ - | Re: Dos navig+int 13h (fwd) (mind) |
VÁLASZ |
Feladó: (cikkei)
|
> > 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 problema az, hogy a DN direkt INT 13 hivasokat hasznal (vagy esetleg
> int 26-ot?, passz).
Az mar megvizsgaltam, hogy int 26h-t hasznal-e.... Azt biztos nem.
Tehat tenyleg akkor a 13h-val kene irjon... Erre mar en is gondoltam :-)
> Szoval, ha a DOS-tol jott a hivas, akkor engedni kell, egyebkent pedig
> write-protect hibauzenettel kell visszaterni.
Yess. Erre nem gondoltam. En is gondoltam ilyen FAT-es meg mas direct
szektorlevedsre viszont ez jo otlet :-)))
> Ezek utan csak a DOS torles fuggvenyevel lehet file-okat torolni, azokat
> viszont mar amugy tudja korlatozni a programod.
Innen mar megy minden !
Koszi szepen mindenkinek !!
> Somogyi Akos
Molnar Szilveszter
Szilveszter Molnar
E-mail:
|
+ - | ++DN (mind) |
VÁLASZ |
Feladó: (cikkei)
|
> Miert kell bantani szegeny DN-t ??????
Ooooo, nem bantom en ! Csak nem ertem miert kell ilyen eros programokat
irni, hogy szegeny programozo majd fogja a fejet :-)
> 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 !!!!!!
> :)))
:-))))))))))) Nem azert irom, mert kedvem telik benne. Nalunk vannak
olyan bunko felhasznalok akik a pascal progikat belepakoljak a norton
konyvtarba, es a c-ben irottakat meg a dos-ba :-(
DE PERSZE AZT MAR MEGTANULTAK HOGY AZ EN PROGIMAT HOGY VERJEK AT. -> ez
csak vicc mert meg nincsen kesz de biztosan rajottek volna :-)
Moszi
E-mail:
|
+ - | DOS NAVIGATOR (mind) |
VÁLASZ |
Feladó: (cikkei)
|
> int 13h, int 26h, blabla :-)
Kozben rajottem, hogy nem tudom csak ugy szimplan megvizsgalni, hogy a
dos ir-e mert meg van nekem egy olyan progim is hogy Stacker :-) Es akkor
az is write-protected-et fog mondani :-< Persze azt is meg kell nezzem,
hogy a Stacker a 13h-val vagy a 26h val ir. Ha a 26h val akkor jo, ha nem
akkor :
mi a megoldas ? :-((((
Szilveszter Molnar
E-mail:
|
+ - | Re: adatok az exe-ben (mind) |
VÁLASZ |
Feladó: (cikkei)
|
>> 1. Kideritteted a programmal a sajat nevet (micsoda.exe) -- ezt egy
>> DOS-hivas megoldja.
>DOS hivas ilyet kozvetlenul nem mond meg, de mondjuk kideritheto
>viszonylag egyszeruen...
Megmond, Istvan, de valoban nem kozvetlenul. Az en FILESPEC fuggvenyem --
ugy ertem, ami birtokomban van, de nem en irtam -- ax=6200h ertekkel hivja
meg az int 21h-t. Visszateres utan a bx altal megadott szegmensbol
kiolvassa a 2ch cimen levo szot, ez az environment blockok szegmense. Itt
keresgel a fuggveny, s egy pillanaton belul meg is talalja a file-nevet.
>> 2. Megnyitod ezt a file-t es kiolvasod belole a meretet, ami a fejlecben
>> megtalalhato. Ez a valodi meret lesz, a hozzamasolt adatfile(ok) nelkul.
>> Innentol pontosan tudod, hogy hol kezdodnek az adataid.
>Erre egyaltalan nincs szukseg. Amit Arp irt, az sokkal egyszerubb: A
>file VEGEHEZ kepest negativ offsettel lehet pozicionalni. Ez tenyleg
>egyetlen DOS hivas.
Igen, de sokszor nehezen hasznalhato. Itt van peldaul Kalen 98 programom,
amelynel az exe vegehez illesztettem az evfordulokat; ezek mennyisege
azonban verziorol verziora valtozik. Ha Arp -- egyebkent valoban egyszerubb
-- modszeret alkalmaznam, mindig fel kellene jegyeznem a programban, hogy
mekkora az adatfile. Ez is megoldhato persze aranylag egyszeruen, de kicsit
mar barkacsolasszamba megy. Elegansabbnak es uzembiztosabbnak tartom, ha a
program magatol intezi el az egeszet.
Csabanak teljesen igaza van, a C-ben megkapod a program nevet. Mivel az
en megoldasomat BASIC-ben irtak, kulon kellett fuggvenyt irni ra -- ha
C-ben akarod hasznalni, egyszeruen kihagyhatod belole ezt a fuggvenyt. Az
exe meretet tudtommal a C se mondja meg magatol.
|
+ - | Re: mesterseges problemak (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Sziasztok!
>> 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.
>
> [...nyissz...]
>
> Vegulis csak oda akarok kilyukadni, hogy az optimalizalas tud lenyeges
> lenni, es nem csak assembly szinten, hanem magasabb szinten (C,C++) is
> van ertelme, [...]
Ehhez annyit szeretnek hozzafuzni, hogy nem ez a fo ok, hogy az a bizonyos
98% teljesen konvencionalisan van megirva. Marminthogy a programozo lusta
es rahagyja magat a compilerre.
Van a szoftvertervezesben nehany alapszabaly, ezek kozul az egyik: ne
optimalizalj! Es, ha belegondol az ember, ennek van ertelme: barmilyen
optimalizalas azzal jar, hogy nehezebben megfejtheto lesz hogy hova akarsz
az egesszel kilyukadni. Istvan irta mar, hogy sokszor Te magad sem tudod
par het mulva, hogy mi is volt ez a "quick hack" akkoriban? Azonban meg ez
sem a fo ok. Hanem, hogy masok szamara lesz erthetetlen a kod. Manapsag
egy nagyobb szoftverprojekt evekig is eltarthat, es az emberek jonnek es
mennek. Namost ugye, ha egy uj programozo jon a csapathoz, akkor milyen
rossz neki (es foleg mekkora anyagi veszteseg a cegnek!), ha hetekig,
honapokig eltart, amig az osszes ilyen kis dologra rajon es csak utana
tudja folytani a fejlesztest. Es mi van, ha csak fel evig marad a cegnel?
Jon az uj ember, neki is elorol kell kezdenie.
A szoftvertervezes es -fejlesztes idealis esetben (az
objektum-orientaltsag elterjedese ota) egy folyamatos, megtores nelkuli
folyamat. A specifikaciot koveti az EER (extended entity relationship),
ezt koveti az OOA (object oriented analysis), es ebbol mar egyenesen
kovetkezik a programkod. Tehat hogy van objektum A, ezzel es ezzel az
eljarassal, stb; tulajdonkeppen az OOA-bol (ha jol van megirva)
automatikusan kellene tudni a source nagy reszet generaltatni, es
szerintem elobb-utobb ez igy is lesz.
(az OO elott itt volt egy nagy tores, amikor az objektum-orientalt
analizisbol egy modularisan felepitett (es nem OO) program keszult).
Barmilyen "trukkozes" rossz hatassal van az egesz projektre. Nem szabad
elfelejteni a tesztelest (ami a projekt minden fazisaban omniprezens <-wow
:) es a karbantartast, ami meg hosszu evekig, evtizedekig is eltarthat.
Tegyuk fel, hogy mint uj programozo kerulsz egy teambe, vagy hogy Teged
biznak meg, hogy egy korabban megirt szoftvert tartsal karban, javits ki
kisebb dolgokat. Namarmost megint csak idealis esetben nullarol indulva
elolvasod a specifikaciot, az EER-t es as OOA-t, es ezek utan azonnal
kiismered magad a kodban, nincsenek meglepetesek. Ha a kod tele van
hack-ekkel, akkor az egesz dokumentacio ami a projektrol keszult, ertelmet
veszti.
En nagyon szeretem a C-t es C++ (az asm-tol mar felek :), de belatom, hogy
szoftvertervezesi szemszogbol nagyon veszelyes nyelvek, mert tul sokat
engednek meg. Bizonyos dolgok, ami pl. egy rendszerprogramozonak aldas,
szoftvermernoknek nagyon veszelyes. Pl. mutatok, mert ha azzal elkezd
valaki hadonaszni, annak ritkan lesz jo vege... Ugy tudom, nem egy
szoftverhazban analizalja a kesz kodot egy komplexitast vizsgalo program,
es ha egy sort vagy kifejezest tul komplexnek talal (a C ugye kifejezetten
elosegiti kriptikus es tulzsufolt programsorok irasat), akkor azt bizony
at kell irnod egyszerubbre...
A Java, mint uj, modern nyelv, egy nagy lepest tesz a szoftvertervezes
iranyaba es el a "piszkos" programozastol, ertsd, nem enged meg olyan sok
trukkot. Pl. hogy nincs pointer-aritmetika (pointer van!), hogy
automatikus a garbage collection, de szerintem legalabb olyan fontos az
interface-ek megjelenese. Tehat en mint szoftvermernok :-) definialok
interfeszeket, es megadom a programozonak: ird meg az osztalyt, ami ezt es
ezt ez interfeszt implementalja. Nem tehet mast, minhogy ezt megirja,
espedig ugy, ahogy azt en akarom. Ha nem felel meg az interfesznek, a
compiler le sem forditja, es mivel az interfesz nagyon pontosan
van definialva, a kesz osztalyt viszonylag konnyen lehet tesztelni.
Most elegge elkalandoztam, a lenyeg az, hogy az optimalizalas nem mindig
optimalis, punktum :-))
Na jo, eleget beszeltem, remelem meg van aki olvassa :-), bye!
Barna
p.s. persze a "mesterseges problemaknak" ennek ellenere is van ertelmuk,
mivel az elet csak ritkan felel meg az "idealis esetnek" ;-)
|
+ - | Re: nagymatrix (memoria allokacio)B (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Hello,
>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
legjobb tudomasom szerint DOS alatt statikus valtozok eseten a hatar
64kB, dinamikusan allokalt valtozok eseten a base 640kB-os memoria
szabadon maradt resze erheto csak el. Ami roppant idegesito ha 32M RAM-od
van. Lehet trukkozni protected moddal azert de nem teljesen trivialis.
A megoldas az lehet hogy ha windows alatti forditoval dolgozol, es egy
u.n. easy windows-tipusu applikaciot generalsz, hol bar nem hasznalsz
semmilyen windows specifikus dolgot de a progi termeszetesen csak windows
alatt fog futni.
(Kulonben Win95 alatt ugy tudom valami 4-8MB per valtozo a hatar (de ezt
csak hallomasbol tudom) vajon igaz ez?).
En is kulonben nagyon keszulok Win95 alatti programozasra a sok unix utan,
csicsas dolgokat muvelni, a Borland C++ Builder Professional editiont
mostanaban annyira piszok olcson meg lehet kapni, kb. $25 a Professional
Edition (jogtiszta! some restrictions apply) amit szoftverhazban kereken
$800-ert mernek de ott persze dokumentacioval egyutt) A heten kell egy
pasi elkuldje hacsak at nem vagott.
marattam,
szindbad.
|
|