Új hozzászólás Aktív témák
-
Jester01
veterán
válasz macikos #1888 üzenetére
Mert a szabvány az #include <iostream>, továbbá using namespace std; ajánlott.
getch ugyancsak nem szabványos, ahol ezt tanítják ott baj van. Természetesen az egész conio.h nem szabványos, a képernyőtörlésre sincs sajnos szabványos megoldás. Ilyen beandadókban általában nincs is jelentősége, sokkal fontosabb (jobb helyeken) az, hogy szabványos kód legyen.Jester
-
Jester01
veterán
válasz cellpeti #1952 üzenetére
Talán mert van vele némi probléma
Pl. az első ciklusod <=3 feltéle már a kötőjelet is nézi, tehát amiatt kapásból hibás lesz minden jó rendszám is. Ugyanezen feltétel esetleg túl is címez a stringen, ha az nincs is 4 karakter. A kötőjel ellenőrzésnél i-re hivatkozni nem túl jó ötlet, ha egyszer azt akarod ellenőrizni, hogy a 4. karakter kötőjel-e, akkor azt írd oda (most ugye a hibás ciklusfeltétel miatt az i itt 4 lesz, tehát az ötödik karaktert nézed). A "-" az string konstans nem pedig karakter, és a feltételben kicsit sok a felkiáltójel.A legrosszabb pedig az, hogy a végén fixen "return 1" van, akármi is az ok változó értéke.
Lehetséges javítás:
int rendszam(const char* s)
{
if (!s || strlen(s) != 7 || s[3] != '-') return 0;
for(i=0;i<3;i++)
{
if(!isupper(s[i]) || !isdigit(s[i+4])) return 0;
}
return 1;
}MOD: jó hát én voltam a leglassabb
[ Szerkesztve ]
Jester
-
Jester01
veterán
válasz tomazin #2056 üzenetére
Én látok ott egy windowsra fordított verziót, az miért is nem jó
Jester
-
Jester01
veterán
válasz klayton#1 #2106 üzenetére
1) legközelebb lehetőleg szövegesen másold be a kódot mert én ugyan nem fogom begépelni, hogy kipróbálhassam
2) a belső ciklusod minden egyes különbségre másol egyet. Először összehasonlítja az e-t az e-vel, stimmel, nem történik semmi. Aztán az e-t az l-el, nem stimmel, másolja az e betűt. Jön az m, nem stimmel, másol még egy e betűt. És így tovább. A segfault azért lesz, mert hosszabb lesz a kimenet mint az eredeti string. Úgy kellene, hogy a belső ciklus csak megállapítja, hogy benne van-e az adott betű a másik tömbben, és utána egyszer másolja ha szükséges.Jester
-
Jester01
veterán
-
Jester01
veterán
Ezt most nem nagyon értem. Egyfelől egy időmérőnek nem kell "futnia": az csak annyi, hogy megjegyzed az időpontokat. Másfelől, ahhoz, hogy elindítsd/megállítsd eleve kell valami végrehajtási szálad legyen tehát egy másik szál innentől kezdve fölösleges.
Ettől függetlenül persze lehet szálakat csinálni windowson is, lásd msdn.
Jester
-
Jester01
veterán
válasz CPT.Pirk #2215 üzenetére
1. A programokat az operációs rendszer indítja, tipikusan másik programok kérésére. A main függvény argv/argc paraméterei a c/c++ nyelv szabványosított formája a program argumentumok kezelésére (mármint nem a nevükre gondolok itt, mert az ugye bármi lehet). Az argumentumokra általában nincs olyan megkötés, hogy nem tartalmazhatnak szóközt. Ha tehát a hívó program beleteszi őket, akkor te meg is fogod kapni. Vagyis csak az a kérdés, hogy a hívó programot hogy veszed rá erre. Windowson a hívó például lehet a parancsablak, a cmd.exe. Ezesetben értelemszerűen idézőjeleket használva valószínűleg jó lesz. Továbbá, ha nem platformfüggetlen kódot írsz, akkor windowson egyben is lekérheted az egész parancssort, a GetCommandLine függvénnyel (bár nem tudom a szóközökkel ezesetben mi lesz).
2. Az argv továbbadása. Az argv nem valami mágikus paraméter, csak egy sima string tömb. Mint ilyen, természetesen akár egészben akár darabokban továbbadhatod másik függvényeknek, pont úgy mint bármilyen más string tömböt. Az argc meg csak egy szerencsétlen int, azzal még ennyi gond sincs.
Jester
-
Jester01
veterán
válasz CPT.Pirk #2217 üzenetére
Ha bővebbet tudnál mutatni a linuxos hibáról akkor abban esetleg tudnánk segíteni.
Ami a kódot illeti: az i,j,len változókat kirakni globálisba nem szép dolog, tedd őket bele az strLen függvényedbe. Az if (i==1) len=0 felesleges mivel ha nem volt argumentum a len úgyis nulla. Az i-t ellenőrizni pedig megtévesztő, hiszen tulajdonképpen az argc-t akarod vizsgálni (persze az értéke ugyanaz lesz, csak logikailag gubancos).
Továbbá szebb lenne, ha a kiírás nem az strLen-ben lenne, hanem a main-ben az strLen visszatérési értéke alapján.
Ha jól értem a logikát, akkor az argumentumok között egy szóközt feltételezve korrigálod a hosszt. Ez ugye addig jó amíg tényleg annyi van. Ha a felhasználó egyetlen argumentummal futtatja akkor nyilván jó eredményt fog adni egyébként.
$ cat >test.c
#include <stdio.h>
int strLen(int argc, char *argv[]) {
int i, j, len = 0;
for (i = 1; i < argc; i++)
for (j = 0; argv[i][j]; j++)
len++;
if (argc > 2) len += argc - 2;
return len;
}
int main(int argc, char *argv[]) {
printf("hossz: %d\n", strLen(argc, argv));
return 0;
}
$ gcc -Wall -O2 test.c
$ ./a.out hello world
hossz: 11
$ ./a.out "hello world"
hossz: 11
$ ./a.out hello world
hossz: 11
$ ./a.out "hello world"
hossz: 13Jester
-
Jester01
veterán
válasz ArchElf #2258 üzenetére
RIP
Mi QNX alatt csináltuk az elosztott házit, Drótos tárgyából ha jól emlékszem. Mondjuk az nekem is megvan még ... összefüggő pacák megszámolása egy képen. Linuxos verzió az több processz + IPC volt, QT alapú vizualizációval
Ez egy teszt kép volt:
[ Szerkesztve ]
Jester
-
Jester01
veterán
válasz RexpecT #2314 üzenetére
Ez egy elég tökkelütött feladat
Az adott tömbben elég sokféleképpen lehet tárolni a halmazt, az egyik módot kingabo fentebb említette. Én most egy másikat mondok, ami valószínűleg közelebb áll a kérdésfeltevő korlátolt elképzeléséhez
Használjuk az x -> h[x] leképezést a számosság tárolására. Vagyis h[0] a 0 számossága, h[1] az 1 számossága, stb.
Ez alapján az adott halmaz leképezése {0, 3, 0, 3, 0} a legnagyobb tárolható elem pedig a 4.Kicsit általánosítva x -> h[f(x)] leképezés lehet, ahol a fenti példában természetesen f(x)=x. Vegyük észre, hogy ennek a leképezésnek igazából az alaphalmaz számosságára illetve az egyes elemek előfordulására van korlátja, nem pedig az elemek nagyságára. Magyarul 5 különböző elemet használhatunk, de azok bármik lehetnek. Például ha f(x)=x-1 akkor máris az {1, 2, 3, 4, 5} alaphalmazzal dolgozunk és a legnagyobb tárolható elem az 5. Mivel a példában csak 2 különböző elem van, ezért a fennmaradó 3 elemet tetszés szerint választhatjuk meg, így bármekkora elemet is tárolhatunk.
Jester
-
Jester01
veterán
válasz TheRolf #2493 üzenetére
Először is, használd a fordítót arra, hogy minél több hibát jelezzen neked. gcc esetén erre a -Wall kapcsoló szolgál. Lássuk mi nem tetszik neki:
t.c: In function 'fordit':
t.c:14: warning: implicit declaration of function 'malloc'
t.c:14: warning: incompatible implicit declaration of built-in function 'malloc'
t.c:14: error: called object 'str' is not a function
t.c:15: error: called object 'out' is not a function
t.c:15: warning: return makes integer from pointer without a cast
t.c: At top level:
t.c:18: warning: return type defaults to 'int'
t.c: In function 'main':
t.c:21: warning: assignment makes pointer from integer without a castAz első kettő azért van, mert nincs meg a malloc prototípusa, ehhez erősen ajánlott egy #include <stdlib.h> (bár nem kötelező).
A következő kettő azért van, mert kerek zárójelet használtál szögletes helyett tömb indexeléshez.
Az ötödik probléma, hogy a main() függvényed visszatérési típusa nincs megadva. Bár C-ben alapértelmezés az int, de azért ajánlott kiírni.
Az utolsó kettő oka, hogy a függvényed visszatérési típusából hiányzik egy csillag, hogy pointert adjon vissza.
Ezeket javítva sajnos további hibákra derül fény:
t.c: In function 'main':
t.c:25: warning: control reaches end of non-void function
t.c: In function 'fordit':
t.c:16: warning: 'i' may be used uninitialized in this function
/tmp/ccle9qDf.o: In function `main':
t.c:(.text+0x89): warning: the `gets' function is dangerous and should not be used.Az első, hogy a main() nem ad vissza értéket. Ezt egy return 0; kiválóan orvosolja.
A második már súlyosabb, azt mondja, az i változónak nincs kezdőérték megadva mielőtt használod. C-ben a változóknak nincs alapértelmezett kezdőértékük.
Végül, a gets függvény használata veszélyes, mivel nincs benne hosszúság ellenőrzés. Ugyan ez nem végzetes hiba de helyette ajánlott az fgets használata.
Jelenleg akkor így néz ki a program ami a fordítónak már nem okoz fejfájást:
#include <stdio.h>
#include <stdlib.h>
int hossza(char *str){
int i=0;
while (str) {
i++;
}
return i;
}
char* fordit(char *str) {
int i=0;
char *out;
out = (char*)malloc((hossza(str))*(sizeof(char)));
while (str[i]) {
out[i] = str[-i-1];
}
return out;
}
int main() {
char betuk[50];
char *z;
gets(betuk);
z = fordit(betuk);
puts(z);
free(z);
//getchar();
return 0;
}(A gets benne maradt egyelőre, lásd később.)
Ezután jutunk el a futási hibákhoz. A felderítésükhöz debugger vagy más diagnosztikai program (pl. valgrind) ajánlott. Példának okáért kapjuk elő a gdb debuggert. Miután beadtuk a stringünket, azt látjuk, hogy a processzor pörög de nem történik semmi. Nézzük meg miben mesterkedik a programunk:
(gdb) r
Starting program: /var/tmp/a.out
hello
^C
Program received signal SIGINT, Interrupt.
hossza (str=0x7fffffffe6d0 "hello\n") at t.c:6
6 while (str) {Ahha. Szóval ott került végtelen ciklusba, mivel az str az biza nem változik. Oda igazából str[i] kellene. Nézzük, jobb lesz-e ettől. Igen, most egy másik ciklusban pörög, aminek a feltétele a megtévesztésig hasonló:
Program received signal SIGINT, Interrupt.
0x00000000004005f5 in fordit (str=0x7fffffffe6d0 "hello\n") at t.c:16
16 while (str[i]) {Innen pedig azért nem lép ki, mert az i nem változik a ciklusban. Tegyünk róla, hogy 1-el növekedjen. Szuper jó, ettől már legalább lefut a program, csak semmit nem ír ki. Nézzük meg például honnan lesz első betűje a kimenetnek:
(gdb) br 17
Breakpoint 1 at 0x40066d: file t.c, line 17.
(gdb) r
Starting program: /var/tmp/a.out
hello
Breakpoint 1, fordit (str=0x7fffffffe6d0 "hello\n") at t.c:17
17 out[i] = str[-i-1];
(gdb) p i
$1 = 0
(gdb) p -i-1
$2 = -1Hoppá, mire is kértük a számítógépet? out[0] = str[-1]. Ez így nem lesz jó, oda nekünk az utolsó betű kellene, ami azt jelenti itt még hozzá kellene adni a string hosszát. Tegyük ezt meg. Csoda, kiírta fordítva a szöveget. Na de minket nem olyan egyszerű boldoggá tenni, ráengedjük a valgrindot is:
hello
==28218== Invalid read of size 1
==28218== at 0x4C25824: __GI_strlen (mc_replace_strmem.c:284)
==28218== by 0x4E8DDCA: puts (ioputs.c:37)
==28218== by 0x400697: main (t.c:28)
==28218== Address 0x518a045 is 0 bytes after a block of size 5 alloc'd
==28218== at 0x4C244E8: malloc (vg_replace_malloc.c:236)
==28218== by 0x40061D: fordit (t.c:15)
==28218== by 0x400687: main (t.c:27)Elismerem ez kissé érthetetlen, de azt szeretné mondani nekünk, hogy a kiírásnál az első 5 byte után a hatodik olvasása nem jó. De miért is akar hatot olvasni, ha egyszer a "hello" csak 5 betű. Jusson eszünkbe, hogy C-ben a stringek végét egy nulla byte jelzi. Írjuk át a programot, hogy ezt vegye figyelembe. Ettől már a valgrind is elégedett lesz.
Végszó:
1) Sajnos az fgets függvény a sor végét jelző entert is eltárolja a pufferbe, így azzal extra izzadnunk kell egy kicsit.
2) gondolom az strlen használata tiltott volt, ezért írtál saját hossza függvényt
3) sizeof(char) definíció szerint 1.
4) a malloc visszatérési típusa void*, és az bármilyen pointerré cast nélkül konvertálható. Lehetőleg kerüljük a felesleges castolásokat.
5) némi visszajelzés a felhasználó felé nem ártFentiek figyelembevételével a végső program:
#include <stdio.h>
#include <stdlib.h>
int hossza(char *str){
int i=0;
while (str[i]) {
i++;
}
return i;
}
char* fordit(char *str) {
int i=0;
int hossz=hossza(str);
char *out = malloc(hossz+1);
while (str[i]) {
out[i] = str[hossz-i-1];
i++;
}
out[i]=0;
return out;
}
int main() {
char betuk[50];
char *z;
int hossz;
printf("string (max %d karakter):\n", sizeof(betuk)-2);
fgets(betuk, sizeof(betuk), stdin);
hossz=hossza(betuk);
if (hossz>0 && betuk[hossz-1]=='\n') {
betuk[hossz-1]=0;
}
z = fordit(betuk);
puts(z);
free(z);
return 0;
}Elnézést a hosszú hozzászólásért, csak igyekeztem halászatot oktatni, nem sült galambot kínálni.
Jester
-
Jester01
veterán
válasz !wannabe #2508 üzenetére
A castolás tulajdonképpen típus ráerőszakolása. Fontos, hogy C-ben ilyenkor (pointerek esetén) nincs semmi konverzió, vagyis a gép elhiszi neked, hogy az a pointer valóban az amire castolod.
Nagyon rossz példa
const char *text = "1234";
int x = *(int*)text;Ebben az esetben x nem 1 lesz, hanem az "1234" memória leképezésének int megfelelője. Ez ascii kódban a 0x31 0x32 0x33 0x34 byte sorozatot jelenti, ami 32 bites little-endian rendszerben integerként 0x34333231=875770417. Tehát még csak nem is hasonlít arra, amit szegény kezdő programozó gondolt. (Már ha nem a még rosszabb int x = (int)text; formát próbálta.)
A castolást lehetőség szerint kerülni kell, de bizonyos esetekben szükséges rossz. Most hirtelen jó példát nem is tudok rá hozni.
Tipikus hibát viszont igen: ez a void* oda-vissza castolása. Szabvány C-ben erre semmi szükség, mivel a konverzió mind a két irányba automatikus. Példák:
Rossz
int *p = (int*)malloc(10 * sizeof(int));
fwrite((void*)p, sizeof(int), 10, stdout);Helyes
int *p = malloc(10 * sizeof(int));
fwrite(p, sizeof(int), 10, stdout);Bizonyos API függvényekhez viszont szükséges castolni, például a bind ilyen:
int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);
Itt az addr argumentum valójában egy sereg struct valamelyike lehet, a címtartománytól függően, például sockaddr_un unix sockethez, sockaddr_in internet sockethez, stb. Ilyenkor castolni kell. Mivel semmi garancia nincs cast esetén, ezért ez semmivel sem jobb mintha az argumentum típusa egyszerűen void* lenne (amihez nem kellene cast), de sajnos a szabványba ez került be. Példa:
struct sockaddr_un my_addr;
...
my_addr.sun_family = AF_UNIX;
bind(sfd, (struct sockaddr *) &my_addr, sizeof(struct sockaddr_un));MOD: ja meg az accept is ilyen, azt meg te is használtad
[ Szerkesztve ]
Jester
-
Jester01
veterán
válasz Jester01 #2524 üzenetére
További vizsgálódás után még az alábbi dolgokat figyeltem meg:
1) a főprogram még azelőtt törli az üzenetsort, mielőtt a gyerkőcöknek lenne esélyük kiolvasni az üzenetet. Mivel az msgrcv hívások sikerességét nem ellenőrzöd ezt nem veszed észre. Lásd még: feladatkiírás 10. pontja.
2a) a főprogram már akkor beteszi a következő üzenetet mielőtt az előző feldolgozása megtörtént volna.
2b) az előző pont miatt az első gyerek például rögvest megcsinálhat több feldolgozást is, ezért a kimenetben összekeverednek az eredmények. Erre azonban semmi megkötés nincs a feladatkiírásban szóval szerintem ez nem baj.
3) ugyanabba fájlba párhuzamosan szeretnének írni, emiatt vesznek el adatok. A fájlt hozzáfűzésre (append) kell megnyitni akkor jó leszJester
-
Jester01
veterán
válasz followme #2540 üzenetére
Ha kicsit figyelmesebben olvasol akkor látod, hogy alapvetően pointerek castolásáról van szó. Egyszerű típusokra jól definiált konverziók vannak amiket a fordító ismer is.
Ettől függetlenül a megadott példát is lehet szépen csinálni:res8 = ~p;
res8 >>= 3;Mindjárt kevesebb zárójelen kell az ember szemének jojóznia.
Az már csak a hab a tortán, hogy a te példád pont az én állításomat támasztja alá, miszerint a castolás "bizonyos esetekben szükséges rossz".
Jester
-
Jester01
veterán
-
Jester01
veterán
válasz CPT.Pirk #2587 üzenetére
Ennek már eleve a fordításnál el kellene "buknia":
c = buffer; Hiányzik egy csillag.
return *buffer; itt meg van egy fölösleges
if (c == "\n") ide karakter konstans kell, aposztrófok között nem idézőjelben
*buffer = *(buffer--); szerkezet nem szabályos
bár az if belsejét szépen behúztad, attól még oda kellene a kapcsoszárójel (így is fordul, csak mást csinál mivel a return *buffer; már nem lesz a feltétel hatása alattA logikáját amúgy sem értem. Ugye a while feltétel eleve növeli a pointert, tehát c-be a következő karakter kerül már. Ha ez \n (akárhol is van, tehát nem feltétlen a string végén) akkor ezt, és csak ezt, megpróbálja felülírni az ezt megelőző karakterrel és itt abba is hagyja a feldolgozást, visszatérési érték pedig a buffer aktuális értéke lesz (tehát nem a string eleje). Ha pl. a bemenet "abc\ndef" akkor a kimenet "cdef" esetleg "ccdef" lesz.
Mivel az a feladat, hogy szedje le az új sor jelet a string végéről, ezért egyszerűen meg kell keresni a lezáró nulla byteot és azt eggyel előrébb hozni ha az előző karakter \n volt.
Jester
-
Jester01
veterán
válasz CPT.Pirk #2589 üzenetére
Ez megint nem jó, mert a ++ az ugyebár megnöveli a változót. Tehát ha megtalálta a \n-t és a rákövetkező byte a lezáró nulla, akkor azt önmagával akarja felülírni. Ha viszont nem nulla, akkor abban a lépésben a buffer kétszer lesz növelve. A visszatérési érték pedig továbbra is rossz, mivel akkor a buffer már a string végére fog mutatni.
Embertelenül túlbonyolítod a kérdést. Összesen annyit kell csinálni, hogy megkeresed a végjelet és megnézed, hogy az előtte lévő karakter \n-e és ha igen, akkor azt felülírod.
Jester
-
Jester01
veterán
válasz CPT.Pirk #2591 üzenetére
Ez még mindig nagyon rossz, mivel most is minden lépésben nézed a \n-t, továbbá a -- és a ++ szépen kiüti egymást.
Igen, majd ha jól működik akkor két 0 lesz a végén de ez mindegy mert a stringnek az első nullánál lesz logikailag vége.
A visszatérési értéknek ha az eredeti paramétert akarod, akkor célszerű másolatot csinálni belőle és azt piszkálni, az eredetit meg békénhagyni.
Jester
-
Jester01
veterán
A második-harmadik szóhoz saját index kell, hiszen nem fog egyezni a bemenő indexszel csak az első szó.
"alma körte banán" itt a körte k betűje a bemeneti stringben 5. pozícióban van, de a második szónak ez a 0. pozíciójába kell kerüljön.A while(i==strlen(str)) helyesebben while(i<strlen(str)), illetve még jobb while(str[i] != 0).
Továbbá C-ben a stringek végére kell egy 0 lezáró is.
Jester
-
Jester01
veterán
válasz WonderCSabo #2628 üzenetére
Az is jó. Sőt, a while(str[i]) is elég, de azért a nullát szeretem kiírni.
[ Szerkesztve ]
Jester
-
Jester01
veterán
válasz Korcsii #2664 üzenetére
c++ rulz, ott csak >> operátor van, semmi más függvény
Azért ezt ne hangoztasd kezdők előtt mert még elhiszik. Példának okáért van std::basic_istream::get() 6 verzióban és még kb ezermillió másik függvény.
Az operator>> különben sem mindenható:
#include <iostream>
#include <string>
using namespace std;
int main(int, char**)
{
string name;
cin >> name;
cout << name << endl;
return 0;
}
$ g++ -Wall test.cpp
$ echo "John Doe" | ./a.out
JohnItt például jól jön a get():
#include <iostream>
#include <sstream>
using namespace std;
int main(int, char**)
{
stringbuf name;
cin.get(name);
cout << name.str() << endl;
return 0;
}
$ g++ -Wall test.cpp
$ echo "John Doe" | ./a.out
John DoeJester
-
Jester01
veterán
válasz kingabo #2669 üzenetére
A lényeges kifejezés az "initial whitespace". Tehát ettől még ugyanúgy megáll az operator>> a szavak között, mert csak a beolvasás elején lévőket érinti. Ráadásul ahogy a link mondja is, bizonyos esetekben a nem eldobott bevezető szóköz rögtön le is állítja a feldolgozást:
#include <iostream>
#include <string>
using namespace std;
int main(int, char**)
{
string name;
cin >> noskipws >> name;
cout << '*' << name << '*' << endl;
cin >> name;
cout << '*' << name << '*' << endl;
cin >> name;
cout << '*' << name << '*' << endl;
return 0;
}
$ g++ -Wall test.cpp
$ echo "John Doe" | ./a.out
*John*
**
**Itt a feldolgozás a szóközön megállt, mert a noskipws miatt nem dobja el, viszont az operator>> ezen overloadja a szóköznél annak kiolvasása nélkül megáll. Szóval ez így sose megy tovább.
Jester
-
Jester01
veterán
válasz Rickazoid #2741 üzenetére
Használnod kellett volna egy debuggert és jól megnézhetted volna, mi a c értéke:
Breakpoint 3, main () at t.c:10
10 switch(c)
(gdb) p c
$1 = 53 '5'
(gdb) c
Continuing.
Breakpoint 3, main () at t.c:10
10 switch(c)
(gdb) p c
$2 = 10 '\n'Így már érted, vagy magyarázzam még?
Jester
-
Jester01
veterán
válasz Rickazoid #2743 üzenetére
De, a te C kódodat futtattam. Egy debuggert mihamarabb meg kellene tanulnod, mert azzal tudod a saját programhibáidat felderíteni. gdb-ben nagyjából 8 paranccsal kiválóan el lehet boldogulni (break, run, step, next, continue, print, x, exit) vagy használhatsz valamilyen grafikus felületet.
Jelen esetben abba futottál bele, hogy a standard input az soronként pufferelt továbbá a getchar szorgalmasan visszaadja a sorvég jelet is. Én például azt írtam be, 5<enter>. Ezt a gép úgy dolgozza fel, hogy az első getchar hívásnál látja, hogy nincs semmi a bemeneti pufferben, tehát beolvas egy egész sort, majd visszaadja az első karaktert (az 5-öt). Erre lefut a switch-ed majd visszamegy a ciklus miatt a getchar-hoz. Ezúttal viszont van még a pufferben valami, mégpedig a sorvég jel, tehát a getchar nem vár és azt adja vissza. Ez ismétcsak a default ágra jut. Hasonló történik akkor is ha másik ágra futsz, a pufferben még mindig benne lesz a sorvég illetve bármi amit a felhasználó még elé írt. Ezt a következő beolvasás vissza is fogja adni.
Ezért tehát mindig célszerű a teljes sort beolvasni majd igény szerint feldolgozni. Például mi legyen, ha a felhasználó 11-et ír be.
Jester
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Huawei P30 Pro - teletalálat
- HiFi műszaki szemmel - sztereó hangrendszerek
- Olasz autó topik (Fiat, Lancia, Alfa)
- Mobil flották
- World of Tanks - MMO
- Okos Otthon / Smart Home
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Windows 7
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Sarokba szorította a Huawei az Apple-t Kínában
- További aktív témák...
- AKCIÓ! Intel Core i7 FÉLKONFIGOK - KÉRHETŐ ALKATRÉSZ IS CPU, RAM, ALAPLAP
- iPad Air 5 64GB M1 WIFI (kék)
- iPhone 14 Pro Max 128gb, makulátlan,garanciális, független
- ASUS H97-PRO alaplap 1150 Intel H97 lapkakészlet, 4xDDR3, SATA 3.0, HDMI, M.2 SSD foglalat
- Macbook Pro 16.2" M1 PRO 10C/16C 16GB - 1TB Magyar billentyűzet - Garanciális 2025.08.04.-ig
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen