Hirdetés
- 4K-s okosmonitor huppant le az MSI tervezőasztaláról
- Almás felhangokat pendít meg a Cougar legújabb, E-ATX-es háza
- A kelleténél jobban lebutítja egyes GeForce RTX 5090-es VGA-it a Zotac
- Komoly technikai frissítést kap a Grand Theft Auto V
- És akkor bevillant a nagy ötlet: miért ne lehetne hűteni egy tápcsatlakozót?
- AMD GPU-k jövője - amit tudni vélünk
- HiFi műszaki szemmel - sztereó hangrendszerek
- Házimozi haladó szinten
- OLED TV topic
- Nem indul és mi a baja a gépemnek topik
- OLED monitor topic
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Szuperhősös mókára fókuszál az új GeForce driver
- Milyen házat vegyek?
- AMD Navi Radeon™ RX 7xxx sorozat
Új hozzászólás Aktív témák
-
llaszlo
veterán
Ezt a -1-es dolgot nem értem.
Én azt logikáztam ki, hogy kiolvasom a bevitt karaktersor adott elemét 'x'. Aztán összehasonlítom a fent elkészített tömb elemeivel. Ekkor ugye mindegy, hogy kis vagy nagybetű. Mindegy, hogy A, a, Á, á stb van.
Ha egyezés van, akkor a másik tömb (ami a számokat tartalmazza) adott elemével növelem a változó értékét.
Amikor elfogytak a karakterek, akkor pedig kész, kilép.Viszont az ékezetes karakterek több helyet foglalnak a tömbben. Most ez a gondom.
Az is megfelel, hogyha az á-t átalakítja a-ra, vagy az Ű-t U-ra, és csak az alap angol karakterek maradnak.
Azzal is tudok tovább dolgozni.Most így néz ki a két tömb
char betu []="AaÁáBbCcDdEeÉéFfGgHhIiJjKkLlMmNnOoÓóÖöŐőPpQqRrSsTtUuÚúÜüŰűVvWwXxYyZz";
unsigned short szam []= {1,1,1,1,2,2,11,11,4,4,5,5,5,5,17,17,3,3,8,8,10,10,10,10,11,11,12,12,13,13,14,14,16,16,16,16,16,16,16,16,17,17,19,19,20,20,21,21,9,9,6,6,6,6,6,6,6,6,6,6,6,6,15,15,10,10,7,7};[ Szerkesztve ]
-
llaszlo
veterán
Köszi. Igaz, a space-t nem vettem figyelembe.
Példa
Dr Kiss József Géza
Ez így jó.
De pl a
Dr. Kiss József Géza-ban a pont karakter már felesleges, vagy bármi más pl: , ; számok stb.A táblázatra fejből nem emlékszem de valahogy így néz ki
A, Á = 1
B = 5
C = 7
D = 11
stbA bevitt szövegből pedig karakterenként kiolvasom az elemeket és ha A van, akkor ugye 1-el növelve az értéket ha B, akkor 5-tel stb. A space és minden egyéb, viszont 0 kell, hogy legyen, vagy nem is ad hozzá semmit sem. Mert ha eleve nincs egyezés a táblázat elemeivel, akkor mehet tovább a következő karakterre.
Megnéztem az isalpha függvényt. Ha jól értem a működését, akkor azzal ellenőrizni tudom, hogy betű vagy más karakter van-e. Ha igen, akkor mehet a táblázattal való összehasonlítás, hogyha nem, akkor beolvassa a következő karaktert. Ha így oldom meg, akkor az isspace nem is kell. Viszont a toupper-t le kell futtatnom előtte.
Azt hiszem, vissza kell mennem az alapokhoz, olyan régen írtam már programot. Viszont jó kis hobbi ez nekem
buherton: Ezt nagyon jó, hogy leírtad. Az alap cézár kódolás feladat amikor egy szöveget a betű eltolással titkosítottunk. Hú de rég volt 99.
-
dobragab
addikt
Igen, ugyanarról beszéltek. Futásidőben már nem tudható a pointer típusa, de fordítási időben baromi fontos. Onnan tudja a fordító, hogy pointer aritmetika / tömbindexelés esetén hány bájt offset-je van a következő elemnek.
int * a = tomb;
int * b = a + 1; // 4 bájttal tolta arrébb
char * c = "text";
char * d = c + 1; // 1 bájttal tolta arrébbFeltéve, hogy az int 4 bájtos.
-
-
Jester01
veterán
memóriacímet tárolnak, ami egy darab szám
Ez persze nem igaz, a pointerek belső szerkezete implementációs kérdés. Például szegmentált memóriamodellben van ugye far pointer is, amiben 2 szám is van, vagy harvard architektúrán a szám mellé még azt is tudni kell adat vagy program memória stb.
Nyilván ha akarom akkor ez 1 szám mivel csak egy halom bit azt meg bármikor felírhatom számként
Az is igaz, hogy a hétköznapi rendszerekben valóban elég egy szám.Ezzel együtt az eredeti kiindulás az volt, hogy az & operátor nem egy számot ad vissza, hanem egy megfelelő típusú pointert. Emiatt aztán (int)&x + 1 és (int)(&x + 1) az nem ugyanaz (kivéve ha véletlenül x mérete 1 byte)
[ Szerkesztve ]
-
maestro87
őstag
Szia, nem mondtam, hogy csak 16 bites számokat kezel, csak azt, hogy amit pl. windows-on beírsz int változót az alapból talán 24 vagy 32 bites emlékeim szerint, míg itt alapból csak 16 bites és előjeles. Előjel nélkülire %u-t kell használni, és ezek a \n, \r-ek sem igazán működnek itt.
Ez utóbbihoz talán a write_lcd függvényemet kellene módosítanom.A 6 tizedes pontosságot hogy számoltad ki, vagy hol írja?
Hogy számolod ki pl. a 24 bites float maximális értékét 3 tizedesjegy pontosság esetén?Amúgy #pragma --FLOAT=32 utasítással most lefordult, mindjárt kipróbálom a változást, de mint említettem már, jelenleg csak egy tizedesjegy pontosságra van szükségem (0.0-tól 100.0-ig), amit most is ki tudok íratni %f-fel gond nélkül,
csak ennek az egész számmal való szorzatát már nem (pl. 6 milliót). Tehát az eredményt már kerekíteni kellene egész típusra!
És ez a 32 bitre való állítás a fent általam leírt hibásan printf-felt egész értékeket még nem befolyásolja.Lehet, hogy még átállok az 10-zel, 100-zal, 1000-rel való szorzásra/osztásra,
de a milliókat akkor sem fogom tudni megjeleníteni.
Egyébként még azt nem értem, hogy mi a különbség a 32 bites float, 32 bites double és a 32 bites long double között.
update: 32-bites float esetén is ugyanezt kapom: printf("%f", 6123456.0); // --> 6123520.000000
Ki kellene számolni már csak kíváncsiságból is, hogy meddig pontos, csak nem tudom hogy kell. Biztos a milliós nagyságrend már nem tetszik neki, de még a százezres sem. Illetve megnéztem az előbb, a %u is csak 65535-öt tud kiírni túlcsordulás nélkül, long-ra (32-bit) pedig végre megtaláltam, hogy a %lu-t kell használni (eddig %ul-lel próbáltam) és ugyanez jó unsigned short long-ra is. 
Bár utóbbi esetben szerintem feleslegesen felkonvertálja a printf függvény a short long-ot 32-bites long-ra, de most annyi baj legyen.[ Szerkesztve ]
-
fraba
aktív tag
(#5274) zka67
Igen, tudom, és az adatlapban is olvastam. A 750 ms az csak akkor szükséges, ha 12 biten ábrázoltatom vele a hőmérsékletet. Próbáltam belerakni 750 ms késleltetést __delay_ms(750);-el illetve szétdarabolva, pl. 200-200-as csoportokban. Le se fut ez a függvény(halmaz). Egyszerűen csak (mintha) átugorja, és küldi a többi mért adatot. Továbbá 16 C-nál magasabb hőmérsékleten tökéletesen működik a várakozás nélkül is. Szóval nem gondolnám, de persze lehetni LEHET!
(#5273) emvy
Erre én is gondoltam, hogy ez itt nagyon gyanús, hogy amikor 15-öt (00001111)-t kéne kijelezni, akkor 127 (11111111) jön helyette. De nem jutottam semmire se. Valami konkrét(abb) ötleted van?
-
zka67
őstag
Sziasztok,
Nem tudom megoldani azt, hogy csak akkor olvasson be egy karaktert az stdin-ről, ha van karakter, magyarul ne várjon a karakterre, ha nincs.
while (1) {
if (checkInput()) doInput();
if (checkTimer()) doTimer();
}nos azt hiszem, sikerült megoldanom a problémát:
void ???func(void *parm) {
pthread_mutex_lock(&mutex);
...
pthread_mutex_unlock(&mutex);
sched_yield();
return NULL;
}
int main(int argc, char **argv) {
pthread_t threadid, inputid;
char f;
f = 1;
while (1) {
pthread_mutex_lock(&mutex);
pthread_create(&threadid, NULL, threadfunc, NULL);
if (f) {
f = 0;
pthread_create(&inputid, NULL, inputfunc, NULL);
}
usleep(10);
pthread_mutex_unlock(&mutex);
pthread_join(threadid, NULL);
pthread_mutex_destroy(&mutex);
}
}ahol az inputfunc a doInput() és a threadfunc a doTimer()
Magyarul, két külön szálon fut a két funkció.
A program alapját a neten találtam, és egyenlőre fogalmam sincs, hogy a pthread_xxx-ek mit is csinálnak pontosan, de a program az elvárásoknak megfelelően működik.
[ Szerkesztve ]
-
Karma
félisten
Nem próbáltam, de szerintem ez működhet.
Stdinen semmi se biztos mondjuk.Nyilván hülyeséget írtam, a getc alaphelyzetben blokkol, ha nem tud karaktert olvasni; ezt felülbírálni meg nem lehet platformfüggetlenül...
[ Szerkesztve ]
-
moseras
tag
Üdv!
uint8_t zreg[8] = {0,0,0,0,0,0,0,0};
#define C zreg[0]
#define B zreg[1]
#define E zreg[2]
#define D zreg[3]
#define BC (uint16_t*)&zreg[0]
#define DE (uint16_t*)&zreg[2]
int main(int argc, char**argv)
{
int i;
*BC += 852;
*DE += 4500;
printf("BC: %d, DE: %d\n", *BC, *DE);
printf("zreg: ");
for (i = 0; i < 8; ++i) {
printf("%d ", (int)zreg[i]);
}
printf("\n");return 0;
}Eredmény:
$ gcc -o 1.exe 1.c; 1.exe
BC: 852, DE: 4500
zreg: 84 3 148 17 0 0 0 0Imi.
[ Szerkesztve ]
Köszi a felvilágosítást.
Ez utóbbihoz talán a write_lcd függvényemet kellene módosítanom.
Bár utóbbi esetben szerintem feleslegesen felkonvertálja a printf függvény a short long-ot 32-bites long-ra, de most annyi baj legyen.
Ú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!
- iPhone topik
- AMD GPU-k jövője - amit tudni vélünk
- Kuponkunyeráló
- CURVE - "All your cards in one." Minden bankkártyád egyben.
- One otthoni szolgáltatások (TV, internet, telefon)
- Fűzzük össze a szavakat :)
- HiFi műszaki szemmel - sztereó hangrendszerek
- OTP Bank topic
- Yettel topik
- Xbox Series X|S
- További aktív témák...
- Nintendo Switch CFW okos! 32+64GB Dual Boot OFW+CFW Tinfoil Hekate + hordozó tok + üvegfólia
- Samsung Galaxy S24 Ultra 5G 512GB, Kártyafüggetlen, 1 Év Garanciával
- Apple iPhone 12 64GB, Kártyafüggetlen, 1 Év Garanciával
- Apple iPhone 12 Pro Max 128GB, Kártyafüggetlen, 1 Év Garanciával
- PHILIPS Series 5500 LatteGo EP5549/70 - ÚJ, BONTATLAN!