Felőlem szavazhatunk is a kérdésről, de abban biztos vagyok, hogy a DOS-os TurboC mind a mai napig 16-bites 'int'-tel dolgozik... továbbá a 16-bites Windows-ra is lehet mindmáig fejleszteni... szóval hagyjuk a manapságot, meg az újabbant, legyünk korrektek és készüljünk föl mindenre
Igen de gondolom azért találták ki ezt a tömbös módszert, mert nem akarták sokszor tesztelgetni, hogy kivülre kerül-e egy lépés, hanem egyszerűen amikor a lépéseket generálom már kezemben van az oszlop és a sor és akkor egyszerűen a tömbből kiválasztom a lehetséges lépéseket majd & a sajátszinekkel és ha 0 t kapok akkor léphetek oda és akkor kevesebb if kell, bár én nem látok bele nagyon a rejtelmekbe ez csak megérzés:) És ez a tömböt az elején legenerálom és akkor csak kiszedem ami most éppen kell nekem, és nem kell folyamatosan erölködnöm a huszár lépésein mindig ifelgetni, hogy kivül kerüle..
En azt csinalnam, hogy minden mezohoz lekodolnam egy byte-on (nyolc biten), hogy a lehetseges 8 ugras kozul meylik legalis. Maguknak az ugrasnak a generalasa mar egyszeru, mert ez csak egy szimpla osszeadas, ha a tabla sorfolytonosan van indexelve.
Nem is kell feltétlenül tömb... elvileg nyolc lépés lehetséges, ezek közül ki kell szűrni azokat, ahol valamelyik vagy mindkét koordináta a sakktáblán kívül kerül...
Az int-et illetoen manapsag a helyzet a kovetkezo:
int 32bit long 32/64 bit aszerint, hogy a gep cimzese 64 bites e.
Ez annyira igy van, hogy pont azert valtoztattak meg 64-bites gepekre sem az int meretet, hogy a letezo programok meg veletlenul se tudjanak elromlani.
Az Opteron gepekre 64-bites kodot generalo forditok (pl. gcc) is 64-bites long-ot general.
A regi 16-bites int-et el lehet felejteni, mert manapsag meg a mobil gepeken is short-ot kell hasznalni erre a celra.
Ok. Köszönöm a válaszokat! Úgy néz ki az összes bábúnak letudom generálni a lépéseit (elméletben, gyakorlatban még csak a bástyát csináltam meg) csak a huszáron gondolkodok. Szóval a huszárt máshogy javasolják mint a többit. A javaslat az hogy csináljunk egy "táblázatot" (a program elején amely végig él) amely mind a 64 mezőre megmondja hogy onnan hova lehet lépni a huszárral egy üres táblán. Tehát itt 2-3 elképzelésem van. 1:Csinálok egy bazi nagy int tömböt kb 400 eleműt amely a következőt tartalmazza tömb[0]="a1-b3", tömb[1]="a1-c2", tömb[2]="b1-a3" stb. Itt még kellene csinálni egy másik tömböt amely megmondja hogy pl ha a d4 mezőn áll a huszár akkor a 202-209 intervallumban vannak a lépések.
2:Csinálok egy 64 elemű tömböt, amelynek elemei listák, azaz tömb[0]="a1-b3" -> "a1-c2" tömb[1]="b1-a3" -> stb. Na most itt nem tudom hogy hogy érdemes, azaz pl itt is érdemes e felvenni egy tömböt amely megmondja hogy a tömb[x] ben lévő lista milyen hsszú? stb
3: csinálok egy 64 elemű ULL tömböt ennek egy elemében eltudom tárolni az összes lépést egy mezőhőz mert 6*8 bit lehet a max. Csak valszeg itt is kellene egy segéd tömb, talán..
Nektek melyik tünik a legjobbnak ill van e jobb ötletetek, javaslatotok?
A strtoul, strtol-nak megadhatsz számrendszer-alapot 2-36 között A #define a fordítónak szól, futáskor nem létezik. Az int rendszerint 2/4 byte-os, a long tipikusan 4 byte, lásd még a sizeof-ot.
OK aszem az oktálist megtaláltam a neten. Illetve itt azt is irják hogy az int 2 bit. (az egyik c s könyvem emlitette hogy ez függhet a hardwaretől ill OS től)
A gdb s topik jó, minden megvan ami kellett nekem eddig.
Milyen számrendszerekben lehet még dolgozni? eddig a hexadec et tudom csak használni és most jó lenne egy 8 as számrendszer ill binárisra is kiváncsi lennék ha már itt tartunk.Ami érdekel konkrétan érdekelne ami a hexánál a 0x azaz a megadáshoz kell mit kell a 8 ill 2 esben ehelyett? Van egy .c fileom ami valszeg sokszor lesz meghivva. Az elején van egy olyan, hogy #define LEPGENT 200 ,nem nagy gond ha ez állandóan lefut tegyem jobb helyre hogy ne fusson feleslegesen le sokszor? Hogy tudom eldönteni hogy az int az én gépemen hány biten van ábrázolva?(irjak egy programot ami az int u=1; u= u<<1;stb vagy van egyszerübb módszer is?Esetleg használjak inkább longot az nem gép ill oprendszer függő?
Annyira nem vagyunk, hogy az egyes függvényeket valamiféle jogosultsági rendszerbe soroljuk be... esetleg még be is kelljen jelentkezniük (azonosító+jelszó+chipkártya)
"Azért ennyire még nem vagyunk... " Ezt nem értem megint:(. Gondolom nem túl jót jelent túl sokat pofáztam vagy miért kaptam??Csak a lényeget mondjam? A gdb ill ddd alapjairól van szép magyar leírás valahol ? pl hogy tudok egy változót végig nyomón követni stb..
OK. A kiiratás most már tökéletes:). Most jön a lehetséges lépések legenerállása:) . Most még csak úgy tervezem hogy szépen végigsétálok a 64 mezőn minden mezőn megnézem milyen bábú áll ott stb (és azt mondták hogy ezt tegyem bele egy nagy tömbbe) Gondolom ez úgy lenne szép ha a változókhoz csak olvasási jogot kapna ez a függvény, ez hogyan oldható meg?
És ugye mielőtt felraktad volna a bábukat, minden mezőre raktál egy "ott nincs senki" jelentésű _nyomtatható_ karaktert (pl. szóközt) is? Meg ugyanezt majdan a lépések után is elvégzed, hogy szóközre (akármire) cseréled a bábut? Mert gondolom a lefoglalt tömböd memóriaszemetét látod a kiíratásnál.
A 'tomb[8][8]' deklaracio egy 64 byte hosszu folytonos memoriat allokal amelyben tomb a 8*i-nel kezdodo darabot cimzi. A problemad az, hogy a C-ben a stringeknek 0 karakterre kell vegzodniuk, ezert a printf(tomb[0]) valoszinuleg az egesz stringet kiirja.
Egy megoldas pl. hogy a tombod sorainak meretet megnoveled eggyel: 'tomb[8][9]', es mindegyik sor vegere beirsz egy 0 karaktert:
Köszönöm a választ. Egyenlőre akkor megirom a programot (ha megtudom), és ha már nagyon akarom fejlesztgetni akkor fogok foglalkozni ilyennel.
Probáltam irni egy megjelenitőt, amely azt csinálná hogy egy 64 elemű char tömbbel megjelenitené melyik mezőn melyik bábú áll. Mivel úgy lenne a szép hogy 8*8 alakban irná ki ezért 'tomb [8] [8]' tömbbe számoltam ki melyik bábú hol áll, majd a printf("%s n", tomb [i]); probáltam kiiratni egy sort(azaz 8 mezőt). Ez jó igy? mert nekem érthetetlen karakterek is bejöttek:), és valszeg a kiiratással van a gond, bár lehet nem:)
C-ben bool helyett altalaban int-et hasznalnak. Minden nemnulla ertek igazat jelent es csak a nulla hamis.
Elönyösebb a maszkot eltolni, igy a fordito optimalis kodot tud generalni, amelyben egyaltalan nem lesz eltolas:
if ( input & (1<<5)) { ... }
A blokkot akkor hajtja vegre, ha az input valtozo 5-ik bitje 1.
Szerintem abbol lehet kiindulni, hogy optimalizalt modban a fordito a assembler hasonlo minösegü kodot fog generalni. Szerintem assemblert gyakorlatilag csak extrem kiveteles körülmenyek között erdemes hasznalni. Ha leakarod ellenörizni a generalt kodot, akkor a "-S" kapcsoloval kell forditani. Az assembler file neve ".s"-re fog vegzödni.
Peldaul a kovetkezo fuggveny 1-et ad vissza, ha az input parameter 5-ik bitje 1, egyebkent 0-at.
Ami egy meglepöen intelligens valasz, hiszen a felteteles ugrast önmagatol atalakitotta egy eltolasse es egy es-operaciova. Ez altalaban gyorsabb, mert a modern architekturakban minden feltetes ugras jelentösen lassithatja a programfutast, mert a processzor a pipeline miatt jump-prediction-t hasznal, ami ha nem jön be alapvetöen lassabb mint jopar müvelet vegrehajtasa.
A fenti megoldas persze csak ebben a specialis esetben lehetseges, amennyiben pl. lebegöpontos szamot adnank vissza, itt a fenti trükk nem müködik:
Itt lathatjuk, hogy most megörizte a 32-vel törtenö maszkolast (tehat az 1<<5 müveletet forditasi idöben elvegezte), valamint kihasznalta a tehat megint eleg jo kodot generalt.
Utoljara nezzük meg, hogy mi törtenik, ha az a következö evvel ekvivalens, de kisse szuboptimalisabb kodot forditjuk (elöször az inputot balra toljuk aztan maszkolunk):
Azaz ugyanaz mint az elöbb, megint nem törtenik eltolas futasidöben!
A tanulsag: nem erdemes tul sokat agyalni alacsony szintü trükkökön, a fordito jo esellyel megtalalja az optimalis megoldast, talan jobbat meg jobbat is, mint ami a programozonak eszebe jutna. Erdemes inkabb a magasabb szintü algoritmikus kerdesekre koncentralni assembler tuningolas helyett.
Erre én is rájö(he)ttem volna:). Nekem itt néha csak 1 bitre van szükségem, néha 8 ra. Bool változó itt nincsen? mert a könyvemben nem találtam:). 1 bit az általad leirt módszerrel való kinyerése mennyivel lassab (kb.) mint egy asm mel kinyert 1 bit a végéről ill elejéről. Hogyan kell beszurni asm kódot? Egyébként az általad leirt módszerben az a jó hogy tetszoleges részből kinyerhető vele bit, forgatás nélkül.
Ez igaz, de azért kell így tárolni (nem én találtam ki), mert ebből könnyebben lehet lépéseket generálni. Általában 14 darab ilyen ugynevezett bitboard van (gyalogok, bástya,huszár,futó,király,vezér }*2+ összes világos +összes sötét bábu). Valahogy ezekkel könnyebb legenrálni hogy honnan hova lehet lépni.
Ez akkor lenne igaz, ha egy figura egyszerre akárhány mezőn jelen lehetne... amennyiben ez nem áll fenn, hanem mindig csak egy mezőn van egyszerre, akkor a 64 bites számodnak mindig egyetlen bitje lesz 1, a többi nulla. Elegánsabb megoldás 6 biten (sőt, 2*3 biten) tárolni azt az egyetlen mezőt, amelyiken van.
"A "long long" 64 bites, de speciel a sakktáblához elég 6 bit. Ellenőrizd: 2^6=64."
Igen valóban az unsigned long long kell nekem:). Azt hogy 2^6= 64 azt még én is tudom:), mivel azonban a 64 mezőről azt kell tárolni hogy ott van-e vagy nincs-e (azaz minden mezőről 1-1 bit információ) ez 2^64 ent jelent.
