- Bluetooth hangszórók
- Vezetékes FEJhallgatók
- Azonnali alaplapos kérdések órája
- Autós kamerák
- NTFS, exFAT, FAT32 – Melyiket válaszd és miért?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Milyen videókártyát?
- Milyen billentyűzetet vegyek?
- Sugárhajtómű ihlette a Zalman CPU-hűtőjét, de nem az üzemzaj tekintetében
Új hozzászólás Aktív témák
-
#3007
Jester01
veterán
WonderCSabo
#3006
Jester01
veterán
válasz
WonderCSabo
#3006
üzenetére
Tévedés:
A bemenet két sorból áll. Mindkét sorban egy-egy szóközt nem tartalmazó, legalább egy de maximum 255 karakter hosszú sztring található, melyeket rögtön sorvégejel követ.
Mind a két sor végén kellene \n legyen. És akkor már nem működik.
-
#3004
Jester01
veterán
WonderCSabo
#3003
Jester01
veterán
válasz
WonderCSabo
#3003
üzenetére
Nekem nem. Hol vágja le a sorvég jelet amit az fgets beolvas?
(gdb)
40 fgets(s,256,f);
(gdb)
41 fgets(d,256,f);
(gdb)
43 kimenet=vizsgal(s,d);
(gdb) x/s s
0x7fffffffe5d0: "abrakadabra\n"
(gdb) x/s d
0x7fffffffe4d0: "rak\n"A vizsgal függvénynek meg kutya kötelessége az egész stringet nézni a lezáró 0-ig, vagyis a \n-t is. Így pedig csak a sor végén fog egyezni.
255-nél hosszabbra nem is kell működnie, de ez már 255-re sem működik, amire még kellene. A tesztelő meg lehet, hogy gonosz módon ki is próbálja azt.
-
Jester01
veterán
Ez nagyon kreatívan megírt program. Ha ember bírálná el, nem sok jó származna belőle.
Mindenesetre a baj az fgets körül lehet, az ugyanis eltárolja a sorvég jelet is. Ezáltal egyfelől csak akkor találod meg a dolgokat ha az éppen a sor végén van, másfelől pedig a 255 hosszú sorokon elcsúszik a feldolgozás (és onnan már nem is jön helyre). Jelen formájában a feladatkiírásban lévő példára sem működik, nem értem ezt hogy nem vetted észre.
-
#2966
Jester01
veterán
LumberJack
#2965
Jester01
veterán
válasz
LumberJack
#2965
üzenetére
Például azért, mert az első if blokk x == 80 esetén kinullázza az x-et, amitől persze teljesülni fog az x < 80 feltétel és a második blokk is végrehajtódik. Esetleg simán else ágat kellene használni (vagy átírni kevésbé kacifántos megoldásra).
-
#2962
Jester01
veterán
Feribacsi555
#2961
Jester01
veterán
válasz
Feribacsi555
#2961
üzenetére
A mínusz jel speciális guglinak, idézőjelbe kell az egészet tenni.
-
#2959
Jester01
veterán
Feribacsi555
#2958
Jester01
veterán
válasz
Feribacsi555
#2958
üzenetére
Google (
) szerint:Indeterminate.
Result cannot be represented in a floating point register.
Most likely the result of 0/0, sqrt(-1) or similar.Magyarul nullával osztottál, negatív számból gyököt vontál vagy hasonló - valós számokon - érvénytelen művelettel próbálkoztál.
-
-
Jester01
veterán
válasz
chabeee
#2916
üzenetére
Rengeteg módon. Például csinálsz egy struct-ot amiben benne van a magyar és az angol szó. Ezután qsort hívással, a megfelelő összehasonlító függvény megadásával, berendezed:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
struct entry
{
const char* eng;
const char* hun;
};
static int compare_entries(const void* a, const void* b)
{
const struct entry* e1 = a;
const struct entry* e2 = b;
return strcmp(e1->eng, e2->eng);
}
int main()
{
struct entry words[] = {
{ "dog", "kutya" },
{ "donkey", "szamar" },
{ "content", "tartalom" },
{ "apple", "alma" },
{ "good", "jo" },
{ "diamond", "gyemant" }};
const int count = sizeof words / sizeof words[0];
int i;
qsort(words, count, sizeof words[0], compare_entries);
for(i = 0; i < count; ++i)
{
printf("%s %s\n", words[i].eng, words[i].hun);
}
return 0;
} -
-
-
Jester01
veterán
válasz
Rickazoid
#2895
üzenetére
Igen, pár változó maradt ki. Ami jelen esetben (is) nagyon fontos volt mivel a típusuk, a méretük és a sorrendjük nagyban befolyásolhatja a program működését. Igen, kitaláltam nagyjából mik lehettek.
"Ezen felül, a buffer2 és buffer3 tömbök induláskor nincsenek inicializálva"
Ez nem is tudom mit jelent.Azt jelenti, hogy C-ben a lokális változók tartalma induláskor nem definiált. Tehát bármi lehet benne. Ezért rossz, ha te valamit keresel benne.
Az általam tanultak szerint a while(Name[I][l]=buffer3[l++]); kifejezés megfelelő.
Nem az, mivel a szabvány szerint nem szerepelhetne benne l és l++ is. A működése ugyanis attól függ, melyik értékelődik ki hamarabb és ezt a szabvány nem definiálja. Ha a jobb oldal számítódik ki először, akkor oda az l eredeti értéke helyettesítődik, de a bal oldalra már a növelt érték kerül. Fordított sorrendben mindkét helyre az eredeti érték kerül.
kellett valami, ami kinullázza a tömb tartalmát
Tehát a tömböt akarod kinullázni. Van neki mérete, tessék szépen végigmenni rajta és kinullázni. for(l = 0; l <= size; ++l) buffer2[l] = 0; (mivel ugye a tömböd mérete size + 1 volt.
Aki nem a debugger használatát tanítja először fejbe kellene kólintani.
-
Jester01
veterán
válasz
Rickazoid
#2893
üzenetére
Tényleg olyan nagy dolog fordítható, futtatható kóddal megtisztelni a segítőkész embereket?
Valahogy kipótoltam, de hogy így most az-e amit te használsz azt honnan tudjam?
Általános jótanács, hogy kapcsold be a fordító figyelmeztetéseit:
warning: suggest parentheses around assignment used as truth value
warning: operation on 'l' may be undefinedEzek a while(Name[I][l]=buffer3[l++]); sorra vonatkoznak.
Következő jótanács, hogy használd a valgrind (vagy más hasonló) programot. Ez például megmutatja, hogy itt-ott a már bezárt f fájlból akarsz olvasni az ff helyett.
Ezen felül, a buffer2 és buffer3 tömbök induláskor nincsenek inicializálva, tehát legalább az első iterációban baj van. A későbbiekben sem látom hogy kerül bele EOF ami különben is int konstans, tehát char változóba nem szabad beletenni.
Ezeket javítva már valamit csinál a program, de hogy az jó-e azt nem tudtam a leírásodból kibogozni.
-
Jester01
veterán
Ugye a for(i = 1; i <= x; i += 2) ciklusod csak a páratlan számokon megy végig, így a végérték vagy x (ha x páratlan) vagy x - 1 (ha x páros). Ezért simán nem lehet megfordítani, mivel a kezdőértéket pontosan kell megadni. Például így: for(i = (x & 1) ? x : (x - 1); i >= 1; i -= 2)
-
Jester01
veterán
válasz
eriktoth
#2871
üzenetére
Az egy dolog, hogy a mi tanácsainkat elengedted a füled mellett, de sajnos a fordító figyelmeztető üzeneteit is (vagy be sem kapcsoltad őket).
1. össze-vissza kevered az egész illetve lebegőpontos típusokat
2. a faktoriális igen hamar igen nagy lesz
3. a ciklusban a változód neked i nem n mint az eredeti képletben
4. a hívott függvény vagy legyen előbb a kódban vagy legyen hozzá prototípus
5. ebben a formában borzalmasan lassú lesz
6. a nyelvek keveréséért azonnali főbelövés jár már két nyelv esetén is, de neked sikerült hármat is ...
7. folyamatosan kérjük, hogy ha már segítségért folyamodik valaki, akkor tiszteljen meg bennünket olvasható kóddal (indentáció és a Programkód gomb használata) -
#2867
Jester01
veterán
WonderCSabo
#2866
Jester01
veterán
válasz
WonderCSabo
#2866
üzenetére
Méginkább nyilván egyikre sincs szükség mert az előző tagból simán adódik a következő. Azt hiszem kingabo is erre célzott.
-
Jester01
veterán
-
Jester01
veterán
válasz
TheRolf
#2825
üzenetére
Itt csak az a baj, hogy az atoi-nek string kell, ami C-ben nulla byte-tal lezárt karaktertömböt jelent. Több lehetőséged is van. Talán a legegyszerűbb, ha a kar[1]-et nullázod. Ekkor ugye így fog kinézni a tömb { x, 0, y, 0 } (a végére az fgets tette a nullát). Ilyenformán a konverzióhoz simán megadhatod az &kar[0] illetve &kar[2] pointereket (ami ugyanaz mint a kar ill. kar+2).
Másik lehetőség egy számjegyű számok konvertálására ha simán levonod belőle a 0 ascii kódját, pl. n = en - '0';
-
Jester01
veterán
válasz
TheRolf
#2813
üzenetére
1) gets-t tilos használni
2) teljesen fölösleges a két változat, a második jó (lesz*) mind a két esetben
3) a math.h is fölösleges
4) ha egyszer int main, akkor illene valamit visszaadni
5) a fordító üzeneteit érdemes megszívlelni (és persze bekapcsolni őket)
6) a kiírás végére illene soremelést tenni
7) a "valamiért nem fut le" szánalmas hibaleírás
8) a ciklusból ki lehet lépni ha már kiderült, hogy nem palindromMOD: * úgy értem, ha a kingabo által fentebb jelzett hibát javítod
-
Jester01
veterán
MOD: ha figyelmesebben olvastam volna akkor láttam volna, hogy az -lm már megvan
Pedig azzal lesz valami, mert ez akkor is linker error. Be tudnád másolni az egész tesztprogramot és a pontos parancssort és hibaüzenetet?$ cat >test.c
#include <math.h>
int main()
{
float c = pow(3, 2);
return 0;
}
$ gcc -Wall -lm test.c
test.c: In function 'main':
test.c:4: warning: unused variable 'c' -
Jester01
veterán
válasz
Hujikolp
#2795
üzenetére
Nem mindegy, csak a <= a helyes.
A for-ban nem felsorolás van, ott a vessző mást jelent (operátor). Egyik részben sem kötelező semmit megadni. Az első kifejezés a ciklus előtt értékelődik ki egyszer, a második a ciklusban maradási feltétel, minden iteráció előtt fut, a harmadik pedig minden iteráció után. -
Jester01
veterán
válasz
Hujikolp
#2792
üzenetére
Pedig elég egyértelmű a hibaüzenet. A % operátor csak egész típusra működik, neked meg float van.
Korcsii: hajnali kettőkor már elnézzük hogy a xor-t valahogy idekeverted
Hujikolp: a feladatra egyszerűbb megoldás lenne a négyzetszámokon végigmenni 100-ig. count = 0; for(i = 1; i * i < 100; ++i) count++;
sokadik mod: ja persze ha konkrétan kétjegyű kell, akkor 4-től nézni.
-
#2791
Jester01
veterán
Feribacsi555
#2788
Jester01
veterán
válasz
Feribacsi555
#2788
üzenetére
Ahogy említették szabvány C-nek ilyen függvény nem része, ez platformfüggő. Windowson nyilván a windows api cuccokat kell használni, pl. SetConsoleTextAttribute (példaprogram ugyanott)
-
Jester01
veterán
válasz
PetyaMIK
#2762
üzenetére
A kigyok az kétdimenziós karakter tömb, vagy ha úgy tetszik egydimenziós string tömb. Ezért nem jó a kigyok[index] != '*', hiszen a bal oldal az char* a jobb oldal meg char. Egy lehetséges megoldás, ha a jobb oldalból is stringet csinálsz, és a megfelelő összehasonlítást alkalmazod: strcmp(kigyok[index], "*") != 0
MOD: Továbbá a ciklus vége előtt már növeled az index értékét, így a while feltétel már másik elemet vizsgál. Egyszerűbb lenne, ha a ciklusmagban lévő if feltétel break használatával kilépne a ciklusból, ami amúgy végtelen lenne.
MOD #2: ja és ha csak a leghosszabb kígyót kell kiíratni, akkor teljesen fölösleges mindet eltárolni egy tömbben.
-
Jester01
veterán
válasz
chabeee
#2755
üzenetére
Hiányzik egy ; a return 0 után, ez gondolom másolási hiba különben nem is fordul. Ezen felül a fordító segítő üzeneteit ne hagyd figyelmen kívül:
t.c: In function 'beolvas':
t.c:19: warning: format '%d' expects type 'int *', but argument 2 has type 'unsigned int'
t.c:21: warning: format '%lf' expects type 'double *', but argument 2 has type 'double'
t.c:24: warning: format '%d' expects type 'int *', but argument 2 has type 'int'Azt próbálja neked mondani, hogy a scanf hívásokban pointert kell átadni, vagyis:
scanf("%d",(unsigned int)t[i].gyev);
-helyett-
scanf("%d",&t[i].gyev);
(annak a castnak amúgy sem volt semmi értelme)Hasonlóan a többire is.
Korcsii: a hiba attól még nem tűnik el. Bár a %u ettől még jó javaslat.
-
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.
-
Jester01
veterán
-
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.
-
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 Doe -
#2629
Jester01
veterán
WonderCSabo
#2628
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.
-
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.
-
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.
-
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.
-
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.
-
#2556
Jester01
veterán
Sk8erPeter
#2553
Jester01
veterán
válasz
Sk8erPeter
#2553
üzenetére
Sőt, elég a következő elemtől nézni a listát
-
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".
-
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ó lesz -
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
-
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.
-
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![;]](//cdn.rios.hu/dl/s/v1.gif)
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.
-
-
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: 13 -
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.
-
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.
-
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. -
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
-
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. -
#1885
Jester01
veterán
Sk8erPeter
#1883
Jester01
veterán
válasz
Sk8erPeter
#1883
üzenetére
Az egésznek egyetlen előnye van: tényleg elhiszik majd, hogy az az illető csinálta aki beadja ...
Ez C és C++ keveréke, globális változókkal, gets használatával, puffer túlcsordulással, boolean kifejezések helyett egymásba ágyazott feltételekkel, string-int keveredéssel, értelmetlen cast-olással, logikai hibákkal, abszolút hibakezelés nélkül és még a saját függvényeit is rosszul használja.
Azt, hogy az utolsó két for ciklus mit csinál nem is értem. Az első kikeresi a maximum árat (ami majdnem jó is lenne, ha nem a minimumot kellene) a másik ciklus pedig nem is tartalmaz a ciklusváltozótól függő kifejezést. Egyszerűen átteszi a talált maximum árat db1-ből db2-be. Utána pedig ezt az árat próbálja indexként használni ... ó jajj. Hogy ezek miért db nevű változók az már csak a hab a tortán.
-
-
Jester01
veterán
Hogy a rákba ne lenne. Gondolkozz már, ha egyszer a task manager is tudja a proci terhelést akkor nyilván meg lehet csinálni. Komolyan nem értem miért olyan nagy kihívás az msdnben megkeresni. Először talán ezt tanuld meg (önállóan információt szerezni) és csak utána programozni
) szerint:
A segédlistát általában azért tiltják mert memóriaigénye van. Ha viszont az eredeti listát használod, akkor nincs plusz memóriaigény.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Pedig azzal lesz valami, mert ez akkor is linker error. Be tudnád másolni az egész tesztprogramot és a pontos parancssort és hibaüzenetet?
Ú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!
- Intel Core i7 6700K / GTX 1660TI / 16GB DDR4 RAM / 500 GB SSD konfig eladó
- Samsung Galaxy S23 128GB, Kártyafüggetlen, 1 Év Garanciával
- Samsung Galaxy A53 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
- Megkímélt állapotú Xbox Series X 1TB eladó. Kitisztítva és újrapasztázva!
- Gamer PC - i5 13400F, GTX 1080ti és 16gb DDR5
- ÁRGARANCIA!Épített KomPhone i5 13400F 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- Dell és HP szerver HDD caddy keretek, adapterek. Több száz darab készleten, szállítás akár másnapra
- FÉL ÁR ALATT! Lian Li UNI FAN SL120 RGB 1db-os és 3db-os ventilátor szett garanciával
- Honor Magic 7 Pro - Fekete - Új kipróbált készülék! Karcmentes gyárilag független! 512GB Memória!
- Eladó szép állapotban levő Apple iPhone 8 64GB fekete / ÚJ KIJELZŐ / ÚJ AKKU / 12 hónap jótállás
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest