- Honor Magic6 Pro - kör közepén számok
- Karaktere biztos lesz az első Nothing fejhallgatónak
- Samsung Galaxy S24 FE - később
- Kedden érkezik a Galaxy S25 Edge
- Samsung Galaxy A54 - türelemjáték
- iPhone topik
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Honor 200 Pro - mobilportré
- Fotók, videók mobillal
- 45 wattos vezeték nélküli töltés jön az új iPhone-ba
Új hozzászólás Aktív témák
-
Karma
félisten
válasz
nonsen5e
#5518
üzenetére
Onnantól kezdve, hogy conio.h (brrr Borland), elég egyszerűen meg lehet oldani. A getch() visszaadja az utoljára lenyomott karaktert, ami a kbhit után nem fog várakozni, hanem visszaadja az utoljára lenyomottat.
Mondjuk szerintem gondold át egy kicsit, hogy mit csinál a != operátor abban az esetben, ha valamilyen okból túlszalad a seconds2 változód a seconds-on, és nem kéne helyette valami más operátor.
Harmadrészt egy középiskolai háziban mondjuk szódával elmegy a busy wait, de afölött már utána kéne nézni, hogy lehet várakozni while ciklusban 100%-on pörgetett CPU nélkül.
-
Karma
félisten
válasz
maestro87
#5441
üzenetére
1) Nekem is feeslegesnek tűnik, mintha nem akartak volna üres zárójeleket írni.
2) A vessző egy alap C operátor, azt jelenti, hogy sorban végrehajtja a három műveletet, és az utolsónak az eredményét adja vissza. Az első két tag elég fontos, ezzel címezi meg az EEPROM adott celláját és engedélyezi az olvasást – ezek nélkül a harmadik tagnak semmi értelme.
-
Karma
félisten
válasz
#36268800
#5279
üzenetére
Nem a double-int konverzióval van baj, sokkal nagyobb probléma, hogy a 34. és a 43. sorban a számítás végző függvényeket (pointerként) adod be a printf-nek, nem pedig meghívod őket.
A double kockázat megoldása annyi, hogy a 7. és a 14. sorban a hányadost 2-ről 2.0-ra átírod.
-
#4963
Karma
félisten
DrojDtroll
#4962
Karma
félisten
válasz
DrojDtroll
#4962
üzenetére
Hibakeresésnél legközelebb másold ide a pontos hibaüzenetet, és hogy fordításkor vagy futáskor történt a hiba.
Egyébként szerintem az a baj, hogy egy 100^4 elemű inttömb bő 400 MB memória lenne, amit stacken nem lehet elhelyezni...
Ha ekkora memóriaterület kell, nem úszod meg a heap használatát (malloc/free), de sokkal célravezetőbb, ha újragondolod a feladatod. Több mint valószínű, hogy nincs szükséged az egész tömbre a memóriában.
-
Karma
félisten
A hiba ott kezdődik, hogy nem használtad a Programkód gombot a forrás beszúrásakor, és így amellett, hogy nehezen olvasható, a [i]-kből mindenféle sima zárójel és dölt írás lett. Erre figyelj oda legközelebb.
Maga a kód rengeteg sebből vérzik, jelölöm amit ránézésre látok:
scanf("%f", &adat->kapacitas); -- mivel a double érték skalár, a scanf függvénynek a címét kell átadnod, ki kell rakni a & operátort hogy ne robbanjon.
for(i = 0; i < (strlen(tomb)-1); i++) ☠-- strlent nem szabad ilyen tömbre használni, csak és kizárólag nullterminált (azaz C) stringekre! A függvényedet úgy kéne módosítanod, hogy a darabszámot is átadd paraméterként.
printf("%i",tomb[i].kapacitas); -- ha egyszer double az érték, miért egészként akarod kiíratni?
De egyébként például a középsőt a fordító is mondja neked, hiszen lefordíthatatlan; miért nem nézed a hibákat?
Egy kicsit lemaradtam az írással
-
-
Karma
félisten
-
Karma
félisten
válasz
don_peter
#4768
üzenetére
De nem egyszerűbb, ha az emberfia először lát egy ilyen rendszert működésben, amin a beágyazott programozás alapjait illetve egyszerűbb elektronikai illesztéseket gyakorolhatja? Aztán ha elég stabilnak érzi a talajt, lemásolja a kapcsolási rajzát vagy saját kútfőből épít sajátot?
dabadab egyébként jól megfogta az egyik gondolatom lényegét
Pont arra gondoltam. A szoftveres "luxus" hiánya (OS, driverek, stb.) szerintem gyorsan megugorható, fel se merült bennem, hogy valaki úgy akarna uC-t programozni. -
Karma
félisten
válasz
buherton
#4762
üzenetére
(És egyben don_peternek is válasz.)
Ez villamosmérnök végzettséggel (de gondolom már műszerész/villanyszerelő szakmával szintén) biztosan nem nagy kunszt; de tisztán szoftveres háttérrel, no meg esetemben az informatikus diplomámmal, azzal az egy félévnyi elektronika tárggyal és egy darab mérés laborral - ahol kész sablon alapján össze kellett pakolni breadboardon két áramkört -, azért nem ennyire triviális.
Nyilván meg lehet tanulni a digitális áramkör építést is, jó szakirodalommal vagy mondjuk kompetens ismerőssel. Én csak annyit akartam mondani, hogy szerintem nem ördögtől való, ha kulcsrakész hobbi platformot vesz.
Ha meg élesben is ezzel akar foglalkozni, akkor a Ti hozzáállásotok követendő, természetesen.
-
Karma
félisten
válasz
buherton
#4758
üzenetére
"Bármi is legyen a döntésed a használt program nyelv a C legyen. Van Basic meg Arduino, meg mit tudom én mi, de az igazi beágyazott rendszer fejlesztő C-ben dolgozik..."
Az Arduino is C, nem írtak hozzá külön nyelvet, csak van egy kezdőbarátabb bootloader és alapkönyvtár. Igazából technikai akadálya nincs annak, hogy valaki átflashelje és nyersen használja.
-
Karma
félisten
válasz
Dave-11
#4753
üzenetére
Van valami konkrét elképzelésed, hogy milyen platformmal szeretnél dolgozni, vagy milyen végcéllal?
Mert ha például csak hobbicélból, akkor az Arduino projekt (AVR) elég népes közösséggel és mindenféle alaplappal, kiegészítővel és libek tengerével rendelkezik.
Rengeteg webshop is foglalkozik vele, úgyhogy rendelni nagyon sok helyről lehet. Itthon a FabLabról tudok csak, de külföldön a SparkFun, SeeedStudio, Adafruit, stb. mind elég jó szerintem.
Ezek a boltok általában saját/közös leírásokkal, blogokkal is rendelkeznek, úgyhogy mindenképp megéri böngészni ismeretszerzés gyanánt is.
-
Karma
félisten
válasz
buherton
#4742
üzenetére
Ilyenről szabványos környezetben nem tudok, de ha a soros portig eljutás kell csak, irányítsd Windowson a comX-re a forgalmat, Linuxon meg a /dev/ttySX-re (ahol X a port száma).
Keresgéltem még egy kicsit, egyre inkább úgy tűnik, hogy a FILE*-ot nem lehet csak úgy helyettesíteni, ez valami avr-gcc sajátosság.
-
Karma
félisten
válasz
alapz@j
#4708
üzenetére
Szerintem az lenne a pláne, ha lenne const char *-os konstruktor (ez heapre másol) és egy char *-os ami átveszi a tulajdonjogot a stringről, és döntse el a kóder hogy melyik releváns.
De egyébként mi az C-ben, hogy konstruktor?
Ha tényleg C-ről van szó, akkor semmi se gátol meg abban, hogy a függvények neve is tükrözze hogy mit csinál a pointerrel. -
-
Karma
félisten
válasz
don_peter
#4635
üzenetére
Képzavarban vagy.
A char, short, int, long, long long különböző méretű, egy számot tároló típusok. Ha nem is a száraz C szabványt, legalább a Wikipédia felsorolását nézd meg.
A méretük fix, nincs olyan hogy egy int 255 alatt csak egy, fölötte több bájt, mindig négy (tipikus fordítóknál, PC-n). A char meg mindig egy bájt. Ha nagyobb számot akarsz beleírni, mint amit ábrázolni tud, akkor átfordul az érték. Pl. unsigned char esetén 255 + 3 = 2.
Gyanús, hogy belekeverted a karakterláncokat gondolatban (char*, char[]).
-
Karma
félisten
válasz
don_peter
#4628
üzenetére
Eszembe jutott még egy lehetőség, és akkor nem kell karakterenként vizsgálnod. Láttam, hogy van printf függvényed, így gondolom sscanf is előfordul. Ha mondjuk %d-t keresel a stringben, és az sscanf visszatérési értéke 1, akkor szám volt, ha 0, akkor meg nem sikerült.
-
Karma
félisten
válasz
don_peter
#4625
üzenetére
Az atoi semmiképp se jó választás, hiszen ha nem számjegy karakterrel találkozik, azt simán kihagyja. A "11A" stringedre ha jól saccolom, a visszatérési érték 11.
Az elemenkénti végignézést javasolnám személy szerint, az nem túl költséges, és biztos jó eredményt ad. Mondjuk az a-zA-Z vizsgálat helyett sokkal egyszerűbb azt nézni, hogy az i-edik karakter >= '0' és <= '9'
Na meg nyilván ha == 0, akkor le kell állni a ciklussal.
alapz@j: Ha a memset ezt az intrinsic megoldást használná, nem lenne az egész optimalizáció vs. biztonság mizéria
-
Karma
félisten
válasz
cellpeti
#4511
üzenetére
Nem jól érted, a beolvasott karaktereket (nagyon helyesen!) nem tárolja a program, csak a darabszámot gyűjti.
Nézd meg a ++gyak[ c ] sort jobban! Vedd figyelembe, hogy a [] operátor erősebb, mint a ++, illetve a tényt, hogy a gyak tömb 256 elemű. No meg nem árt az az ismeret hozzá, hogy a char típus nyolc bites, úgyhogy egy beolvasott karakter 256 különböző értéket vehet fel.
-
Karma
félisten
válasz
don_peter
#4483
üzenetére
Igen, pontosan erről írtam, hogy nem kéne így csinálni, ha nem muszáj. Márpedig desktop környezetben (szemben egy beágyazott rendszerrel) nem valószínű hogy ez fennállna.
A probléma a globális változókkal az, hogy a függvény újrafelhasználhatóságát és olvashatóságát is egyaránt rontja. Az előbbit azért, mert egy közös memóriaterületet piszkál amihez más függvény is hozzáfér és így elronthatják egymás dolgait. A másikat meg azért, mert a függvényen kívülre kerül az az adat, amivel dolgozik.
És végül azért is célszerű már most leszokni a globális változókról, hogy ne alakuljon ki rossz kódolási stílus mielőtt más nyelvekre mész tovább.
-
Karma
félisten
válasz
don_peter
#4467
üzenetére
Lebegőpontos számot hány tizedesjegyig szeretnél számolgatni? A definíció szerinti pontatlanságon túl ez is egy fontos szempont.
Továbbra is fenntartom az állításomat, hogy ez nem egy számítási, hanem egy karakterkezelési feladat. A tizes számrendszer emberi fogyasztásra alkalmas csak egyébként is. Jó szórakozást hozzá, én kiszálltam.
-
Karma
félisten
válasz
don_peter
#4463
üzenetére
Például úgy, hogy nem számként olvasod be a scanf-fel, hanem szövegként (pl. az fgets függvénnyel).
A feladathoz szokás adattípusokat választani, nem pedig hangulatból.
Azt mondjuk nem tudom, hogy ha valóban és szigorúan egy szám a bemeneti adat, akkor osztogatni éri meg jobban, vagy egyszer átkonvertálni stringbe és azon futtatni a ciklust. A paraszti eszem szerint a string, mert sokkal olvashatóbb, hogy mit csinálsz.
-
-
Karma
félisten
válasz
buherton
#4416
üzenetére
A legtöbb nyelv platformfüggetlen. A tényleges munkavégzéshez bevonzott frameworkök meg nem (merthát lehet több féléven át helloworldözni STL-el, de a valóságban azért hálózat, adatbázis, IPC, meg ki tudja mi jön szembe). És máris nem olyan fontos szempont.
Meg ugye a Linux desktop kit érdekel
</troll>A Vuze mindig Java-alapú volt szerintem, még Azureus korában is. Az OpenOffice meg főleg natív, Java kiegészítésekkel.
-
-
Karma
félisten
válasz
TheProb
#4401
üzenetére
Az strcat_s azért jó, mert odafigyel arra, hogy a célterületből véletlenül se szaladjon ki. Ha egy négy hosszú blokkba beleírnád azt, hogy "MCCXXXIV", akkor az strcat kifut és felrobban, a safe változat beírja hogy "MCC" és csöndben megy tovább.
A debuggert használod most is, csak tud sok hasznos dolgot még
Például a programsoraid mellett bal oldalt kattintasz, breakpointot raksz be, aminél a program megáll és lépésenként követheted a menetét.buherton: Tényleg előfordulhatnak felesleges warningok, de ez egyáltalán nem az! Konkrétan elkerülhető lett volna a crash. Az strcat_s tényleg nem szabványos, de az strncat igen, ami szintén egy biztonságos alternatíva más platformon.
Meg úgy egyébként a warningok azért vannak, mert valamit rosszul csinál az ember. Tanulásnál különösen fontos megérteni hogy mit...
-
Karma
félisten
válasz
TheProb
#4399
üzenetére
Túl kevés memóriát foglalsz, ezért robban fel. n = 4, de az eredmény bőven hosszabb ennél
Ha azt nézzük, hogy egy számjegy római alakja maximum 4 karakter lehet, a 4*n+1 byte biztosan elég lesz. Arra átírtam a callocot, és ki is írta az eredményt hiba nélkül.
Egyébként megéri IDE-vel debuggolni a programot. Egyrészt menet közben látod hogy melyik változód milyen értéket vesz fel, másrészt egy kicsit több infód lesz az összeomlásról is, nem csak hogy "kifagy".
-
Karma
félisten
válasz
TheProb
#4393
üzenetére
2) Mert amikor a malloc lefoglalja a területet, az még korábbi szeméttel van tele. Bármi lehet ott, beleértve a Shakespeare összest
Azért kell a 0, hogy biztosan üres string legyen belőle.Alternatívái a memset függvény (az egész területet egységesen nullázhatod vele, illetve a malloc helyett calloc fv. kapásból tiszta területet ad.
-
Karma
félisten
válasz
TheProb
#4387
üzenetére
Az előző álláspontomat szem előtt tartva azért csak kifejtem egy kicsit.
Az alapprobléma az, hogy C-ben és más alacsonyabb szintű nyelveken a memóriakezelést tudatosan kell csinálni, mert nincs az ember alatt védőháló. Mindig tisztában kell lenned azzal, hogy egy adott változó, tömb, karaterlánc hol jön létre, és mikor, ki által fog megsemmisülni. Olyan meg soha nincs, hogy a semmiből memória fakad és pont azt csinálja amit szeretnél.
A mutatott kódodban a romai változódat úgy deklaráltad, hogy egy 20 karakteres tömb, ami a függvényen belül él csak, amint véget ér, felszabadul, te meg nem férhetsz hozzá többet. Ez a sorsa mindennek, ami a stacken jön létre. A befoglaló függvény végén kaputt.
Ilyen minden lokális változó függvényen belül, a függvényeknek átadott paraméterek, az egymás után láncolt függvényhívások köztes eredményei, stb.
Memóriafoglalás tekintetében még két lehetőséged van: a magyar oktatásban "dinamikus memóriának" csúfolt heap; illetve nagyon leegyszerűsítve a "globális változók", a static terület. Utóbbinak inkább ne játssz a gondolatával se.
A programodat azon a két módon lehet megjavítani, amit az előbb is írtam:
1) vagy behozod a heapkezelést és az eredményt oda mented (malloc/free);
2) vagy egy olyan függvényt írsz, mint például az snprintf: a hívó fél gondoskodik arról, hogy legyen hova tenni az eredményt. Javaslom, hogy nézd meg annak a függvénynek a leírását.Ez utóbbi azért különösen jó, mert maga a rómaira átalakító függvényednek nem kell törődnie a memóriakezeléssel egyáltalán. Nem érdekli, hogy a hívója hol foglalt memóriát (stack/heap/static), csak az átalakítással kell törődnie. Nem az ő felelőssége.
Az intes részre nem tudok válaszolni, mert nem sikerült értelmeznem a kérdést.
-
Karma
félisten
válasz
TheProb
#4385
üzenetére
Kapásból a char visszatérési érték helyett szerintem te char *-ot akartál inkább visszaadni -- a teljes számsort egyetlen karakter helyett.
Másrészt a stacken létrehozott char tömböt visszaadni öngyilkosság (a függvény végén megsemmisül -> érvénytelen pointer -> GAME OVER ☠).
Két lehetőséged van: vagy mallockal foglalsz egy dinamikus memóriaterületet, aminek a kezdőcímét adod vissza a függvény végén (és a hívónak fel kell majd szabadítania); vagy úgy írod át a függvényt, hogy bemenő paraméterként kapja meg azt a char tömböt (és annak max méretét), ahova az eredményt írhatja.
-
Karma
félisten
válasz
Jester01
#4363
üzenetére
Na igen, a qemunál karcsúbban elég nehéz megúszni
Axioma, az hogy big endian valami, még nem sok mindent definiál szerintem. Kérdés az architektúra (ARM, MIPS, SuperH, MicroBlaze, stb.), meg a szoftverkörnyezet is (Linux, valamilyen RTOS, nyers kód a vason). Csak mert ettől is függ, hogy mit kéne emulálni vagy szimulálni.
Szerk.: na jó, második nekifutásra mégse olyan fontos kérdések, mert maga a program elmondásod szerint elég minimalista. Ettől függetlenül nem nagyon lehet megúszni a QEMU-t és a Limux telepítést, csak hogy legyen min futtatni.
Itt egy MIPS útmutató, és itt ugyanez SPARC-kal. Valamelyiket lenyomod, és kész is leszel
-
Karma
félisten
válasz
tototos
#4241
üzenetére
Ha törölni akarod azt a szakaszt, akkor ÉSelned kell egy olyan számmal, ami a kívánt bitszakaszon 0, körülötte 1. Ha beállítani, akkor meg VAGYolnod kellegy olyannal, ami a szakaszon 1, mindenhol máshol 0.
Pl. 01010101 & 11100011 = 01000001,
Ill. 01010101 | 00011100 = 01011101Persze az előbbi megoldás teljesebb, mert a maszkot is megcsinálja és konkrét értéket is tud
-
Karma
félisten
Gyanús hogy azért nem fogadta el, mert azt akarta, hogy kézzel implementáld le ugyanezt. A helyszínen kellett volna kifejtetni vele az ítéletét.
Az oldalon lévő szöveg is csak annyit mond, hogy lassú lehet – de ez éppúgy igaz arra is, ha kézzel mallocolsz nagyobb területet, átmásolod memcpyval, és felszabadítod az előzőt.
A kulcsmondat igazából ez: "Ne írjunk olyan programokat, amelyek gyakran méreteznek át tömböket!"
A szabvány alapján nincs arra garancia, hogy ha kisebbre reallocolsz, akkor nem fogja mozgatni a memóriát. Mindenképpen le kell kezelned a visszatérési értéket helyesen, azaz nézni a NULL választ, és nemNULL esetben kicserélni az előzőt siker esetén; ha fel-, ha leméretezel.
-
Karma
félisten
válasz
buherton
#4217
üzenetére
"Szerintem azért, mert sokan elfelejtik, hogy a realloc-nak a visszatérési értékét kell odaadni a pointernek."
Pont ezt nem szabad csinálni azelőtt, hogy megnézné az ember hogy NULL-t adott-e vissza a realloc – mert ha igen, akkor elveszted az eredeti memóriaterületet.
Ettől függetlenül se a realloctól, se a calloctól való félelmet nem értem az oktatásban, bár lehet hogy anno megmagyarázták; én meg elfelejtettem.
-
Karma
félisten
válasz
buherton
#4197
üzenetére
Már hogyne volna C stílusú ez a fajta zárójelezés.
Amellett, hogy Ritchie eléggé a nyelv alkotója, nagy open source projektekben is előfordul, hogy ez a forma mellett döntenek.De persze az is gyakori, hogy új sorba rakják. C-ben én is úgy szoktam, de ettől nem lesz univerzális igazság.
-
#4104
Karma
félisten
Dementor01
#4103
Karma
félisten
válasz
Dementor01
#4103
üzenetére
Az shmget után kéne egy shmat (attach), hogy szerezz egy pointert a memóriaterületre. Ez, meg még sokkal több (pl. szemaforok) elég jól le van írva ezen az oldalon.
-
Karma
félisten
válasz
buherton
#4094
üzenetére
Hát de az nem fasza, hogy lefordítja az ex_init4-et egyszer, aztán az ex_task4-et is (amiben benne van az include miatt az ex_init4 tartalma, és ezért van benne __heap_start...), és egymás mellé rakja őket. Elég egyértelműen rossz felépítés.
Rá kell venned az Eclipse-et, hogy csak az ex_task4-et fordítsa le, vagy vedd ki az include-ot és hagyd hogy a linker tegye a dolgát.
-
#4051
Karma
félisten
krisztianAMG
#4050
Karma
félisten
válasz
krisztianAMG
#4050
üzenetére
Elvileg ha az a _kbhit() függvényhívás nem lenne ott, ennek a kódnak működnie kéne - az F1-12 és más spéci gombok kezelése már benne van a switchben (00 és E0). Próbáld meg azt az if-et kivenni, egyébként sincs semmi értelme.
Ezt most csak spekulálom, de szerintem ha az benne van, végtelen ciklusban pörgeti a CPU-t (egy magot 100%-on), amíg nem ütsz le egy billentyűt. Ami nagyon gáz.
-
Karma
félisten
A C standard qsort függvény tényleg nem stabil, azaz átrendezheti az egyenlő elemeket.
Viszont nem kell n!-szor végigjárnod a tömböt (ez még a legegyszerűbb beszúrásos rendezésnél is rosszabb gondolat, ami csak n^2-es lépésszámú).
Nézz szét a rendezési algoritmusok között, keress egyet ami tetszik és stabil, és implementált. Javaslom az összefésüléses rendezést, ahogy a wiki is említi, a C++ STL-ben ez érhető el stable_sort néven.
(De ha kicsit keresgélsz, találhatsz implementációt készen is. Nem teszteltem.)
-
-
Karma
félisten
-
#3979
Karma
félisten
PumpkinSeed
#3978
Karma
félisten
válasz
PumpkinSeed
#3978
üzenetére
Elkezdtem szerkeszteni a hozzászólást, csak közben spontán meeting lett
Van egy nagyon súlyos hiba: 1-től indexeled a tömböt, nem pedig 0-tól. Ezzel az első elem kimarad az összehasonlításokból, így hülyeség a vége.
A fordított sorrend, amit bizonyára tapasztalsz, az meg azért van, mert a belső ciklusodat nem az első elemtől, hanem i+1-től kell indítani. Enélkül amellett, hogy túl sokszor mész végig a teljes tömbön, még egyszer megfordítod az egészet...
Ha ezt javítod (0-tól kezdeni a külső, i+1-től a belső ciklust), már működő négyzetes lépésszámú (azaz lassú) rendezést kapsz.
De nem lesz ettől még buborékrendezés, mert annak a sajátossága, hogy az összehasonlítások és cserék mindig szomszédos elemek között történnek (pl. J és J+1).
Papírforma szerinti kiválasztásos rendezéssé könnyebb átalakítani, ha nem cserét végzel a belső ciklusban, csak megjegyzed a legkisebb szám indexét, és a belső ciklus után csinálsz egy cserét az i. és a minimumelem között. De annyira nem kritikus.
-
#3977
Karma
félisten
PumpkinSeed
#3976
Karma
félisten
válasz
PumpkinSeed
#3976
üzenetére
Nem, akkor lenne buborék rendezés, ha a szomszédos elemeket cserélgetnéd.
Ez most egy sok felesleges kört futó valami -
#3910
Karma
félisten
PumpkinSeed
#3909
Karma
félisten
válasz
PumpkinSeed
#3909
üzenetére
Egy egyszerű Windows alatti megoldás, ha fogod az econio forrását, és együtt fordítod a programoddal. Nem véletlen, hogy Czirkos is ezt ajánlja
A C Free-t nem ismerem, de biztos van valami egyszerű módja, hogy a projektedhez add.
-
#3900
Karma
félisten
PumpkinSeed
#3899
Karma
félisten
válasz
PumpkinSeed
#3899
üzenetére
Egy egyszerű megoldás, ha a koordináták azonnal léptetése előtt megnézed, hogy lehetséges-e az adott lépés (korlát, pályaszéle, akármi), és ha nem, akkor nem állítod be
-
Karma
félisten
válasz
tototos
#3847
üzenetére
A válasz meg még mindig az, hogy írj egy
uint16_t signal_get_id(const signal_struct const* signal)
{
return signal->id;
}függényt a signal.c-be, és a struktúra tagdefinícióját is átrakod oda. A headerben meg csak a forward deklarációk maradnak, így ha a headert használja valaki, nem tudja még a tagok offszetjét ye, ergo nem tudja változtatni.
-
#3846
Karma
félisten
PumpkinSeed
#3845
Karma
félisten
válasz
PumpkinSeed
#3845
üzenetére
Noshát. A game loop nagyon leegyszerűsítve egy végtelen ciklus, ami addig tart, ameddig a játéknak nincs vége. A ciklusmagban pár dolgot kell elvégezned kötötten:
1) Fogadnod kell a felhasználótól a bemenetet. Ez lehet polling jellegű (amikor ideérsz, megnézed milyen gombok vannak lenyomva), vagy eseményalapú, de az előbbi egyszerűbb.
2) Frissítened kell a szereplők állapotát egy lépéssel (folyamatos idejű játéknál egy valamekkora időszelettel). Ehhez felhasználod az előzőleg begyűjtött inputot, meg az esetleges AI döntéseket.
3) Frissíted a világ állapotát, azaz kezeled az ütközéseket, halálokat, születéseket.
4) (legegyszerűbb eset) Újra kell rajzolnod a képernyőt.
5) Be kell aludnod párszáz milliszekundumra.Ezt kell ismételgetned.
Az SDL, Allegro és társai mind ehhez adnak alapot. -
#3844
Karma
félisten
PumpkinSeed
#3843
Karma
félisten
válasz
PumpkinSeed
#3843
üzenetére
Mi a kérdés? A kígyó mozgása konkrétan (azaz hogyan tárold a kanyarodásokat), vagy maga a folyamatos léptetés (game loop)?
-
Karma
félisten
válasz
Vasinger!
#3832
üzenetére
Hátde az első sorban megírtad a megoldást, miért nem használod ugyanezt a szintaktikát a nullától különböző indexre?
Egyébként halálfejesen rossz megoldás, mert túlindexeléssel reccsen, ha a string végén szóköz van. Miért nem touppereled meg az egész stringet rendezésnél? Megspórolod a szóközkereső mágiát.
Másrészről viszont az ékezetes karakterekkel csak a baj van. Ezt a problémát már sokszor megoldották a világban, úgy nevezik, hogy collation.
-
Karma
félisten
válasz
tototos
#3810
üzenetére
Persze hogy van, csak egy kicsit el kell rugaszkodnod a struktúrától. A megoldás az ún. getter/setter függvények írása, amivel szabályozod a hozzáférést.
Röviden írnod kell olyan függvényeket, melyeknek az első paramétere egy pointer a struktúratípusodra; a getternél nincs más, a setternél meg ott az új érték másodiknak. És csak ezeket a függvényeket használod a struktúrád birizgálásához, közvetlenül nem nyúlsz bele.
C-ben ezt egyébként elég könnyen garantálni is tudod, ha a struktúrád definícióját külön .c fájlba rakod.
-
Karma
félisten
válasz
buherton
#3751
üzenetére
Még csak most üzemelem be a C környezetemet az ellenőrzéshez, de szerintem nem a write, hanem a readFile függvényed hibás.
Történetesen én akárhogy nézem, azt látom a kódban, hogy a db tömbödet a firstPart és a secondPart (stacken) egyszer létrehozott címével töltöd fel - azaz a printffel azonnal a ciklusban kiírva jól mutat, de valójában csak két stringed van a program élete végéig, és ezeket vágod felül folyton.
-
Karma
félisten
Najó, ez csak pedantéria, és ahogy nézem Linuxon nincs is rá szükség - az IGNPAR flaggel az egész hibakezelést ki lehet hagyni a képletből.
(Tök izgalmas ez a feladat
Kár hogy nem tudok kísérletezni ilyennel élesben. Bár lehetne íeni egy szimulátort FPGA-ra, ami ezeket a jeleket tolja ki.) -
Karma
félisten
válasz
Jester01
#3743
üzenetére
Szerintem inkább SPACE paritás kéne, akkor kevesebb hiba generálódik (a datagram kezdőbyte-oknál).
A linkelt oldalon van is erre egy Visual Basic kód (a DOS-os közvetlen UART programozáson túl, amire manapság AFAIK már nem nagyon van lehetőség), tegnap este jól belealudtam az olvasásába.
Pont arra gondoltam. A szoftveres "luxus" hiánya (OS, driverek, stb.) szerintem gyorsan megugorható, fel se merült bennem, hogy valaki úgy akarna uC-t programozni.
Kár hogy nem tudok kísérletezni ilyennel élesben. Bár lehetne íeni egy szimulátort FPGA-ra, ami ezeket a jeleket tolja ki.)
Új hozzászólás Aktív témák
Hirdetés
● olvasd el a téma összefoglalót!
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Cyberpunk 2077
- A fociról könnyedén, egy baráti társaságban
- Lakáshitel, lakásvásárlás
- Milyen belső merevlemezt vegyek?
- Spórolós topik
- EA Sports WRC '23
- TCL LCD és LED TV-k
- Honor Magic6 Pro - kör közepén számok
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- További aktív témák...
- AKCIÓ! HP Elitedesk 800 G1 USDT mini asztali számítógép - i7 4770S 16GB RAM 128GB SSD Intel HD
- BESZÁMÍTÁS! 1TB Western Digital SN850X NVMe SSD meghajtó garanciával hibátlan működéssel
- AKCIÓ! VALVE INDEX virtuális valóság szemüveg garanciával hibátlan működéssel
- Csere-Beszámítás! RTX Számítógép játékra! I5 13400F / 32GB DDR5 / RTX 4070 Super / 1TB SSD
- ÁRGARANCIA!Épített KomPhone i5 12400F 16/32/64GB RAM RTX 3060 12GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: Promenade Publishing House Kft.
Város: Budapest