Új hozzászólás Aktív témák
-
Jester01
veterán
válasz m0h0senator #1237 üzenetére
A legnagyobb közös osztóhoz a közös prímtényezőket kell venni a legmagasabb közös hatványon. A többszöröshöz meg prímtényezők úniója kell. Legalábbis én így emlékszem.
Jester
-
Jester01
veterán
Az a veszélye, hogy a szabvány nem rögzíti előjeles vagy nem. Ha valakinek ez fontos, akkor feltétlen írja ki, hogy unsigned char vagy signed char ellenkező esetben érheti meglepetés.
Például az á betű kódja iso8859-2 szerint 225, de ha a char véletlen előjeles akkor a naív if (c == 225) bizony nem lesz jó:
#include <stdio.h>
int main()
{
char c = getc(stdin);
printf("c == 225: %d\n", c == 225);
return 0;
}$ gcc -Wall t.c
t.c: In function 'main':
t.c:6: warning: comparison is always false due to limited range of data type
$ echo á | ./a.out
c == 225: 0
$ gcc -Wall -funsigned-char t.c
$ echo á | ./a.out
c == 225: 1Jester
-
Jester01
veterán
Mégpedig azért, mert a scanf egy borzasztó rossz függvény terminálról olvasáshoz.
Ha debuggerrel vagy egy kiíratást betéve megnézed mi lesz a gyalog változód valószínűleg egyből kiszúrod, hogy bizony a bástya bekérés után a pufferben maradt egy (vagy kettő) soremelés karakter és az kerül oda.Gyors megoldásként ha a második scanf formátumstring elejére teszel egy szóközt akkor már jó lesz. (Persze ahogy cucka kollega mondta, csak simán az értékeket hasonlítsd össze.)
Beolvasáshoz amúgy fgets és sscanf párosa ajánlott, megfelelő hibakezeléssel.
Jester
-
Jester01
veterán
Hát ez elég szájbarágósan le van írva. Meg tudod mondani melyik rész okoz problémát?
Votyesz13: te meg lehagytad a feladatot. De a for az ciklus tehát ha valamit ismételni kell akkor használd. A switch meg csak egy felturbózott if amit akkor használunk ha azonos kifejezés különböző értékeit akarjuk vizsgálni.
Jester
-
Jester01
veterán
Pl. úgy, hogy nem intet használsz, hanem longot, ami mindig 32-bites.
Mindig? Na ne viccelj!kikiáltja C++ programozásnak, pedig ez csak egy C program, C++ fordítóval lefordítva,
Azért mert egy adott program ránézésre esetleg nem annyira objektum-orientált vagy ilyesmi, azért még meg lehet írni c++-ban. És persze semmi akadálya, hogy az implementáció során osztályokat használj pl. a "Program", "Terminal", "Executor" (ez egy absztrakt osztály lenne), "Simulator" (ez meg implementálja az Executor-t). Így ha teszem azt később ki akarod bővíteni azzal, hogy vezéreljen egy usb portra kötött 3D robotot akkor csak egy új osztály kell ami az Executor-t implementálja.cucka: Mivel a feladat specifikálta, hogy ezt a 3 byteot kell belegyömöszölni az int-be ezért feltételezhető, hogy az adott architektúrán legalább 24 bites az int. Ha meg több az tök mindegy. Egyszerű bit műveletekkel meg lehet oldani. Amúgy ha ettől a feladattól elvonatkoztatva valamikor adott bitszámú int-re van szükséged, akkor az stdint.h-ban laknak olyanok, hogy int32_t meg int_least32_t és társaik.
Jester
-
Jester01
veterán
Gondolom a tíz elemű tömb definiálása és a tízszer három szám beolvasása nem okoz problémát az ellenőrzéssel együtt sem.
Egy adott koordinátahármas int-be pakolásához először mindegyiket az adott formára kell hozni, pl: if (x < 0) x = 0x80 | -x;. Ezután pedig bit eltolás művelettel egybe lehet őket tenni, pl: int step = (x << 16) | (y << 8) | z;Jester
-
Jester01
veterán
Az fscanf szintaxisa 2 karakter beolvasására: fscanf(bemeneti fájl neve, "%c %c", &a, &b)
Nem a fájl neve kell oda, hanem a megnyitott fájl pointer. Karakter olvasáshoz az fgetc függvényt kell használni ami szintén a fájl pointert kapja és visszaadja a soron következő karaktert. A getchar() ekvivalens egy fgetc(stdin) hívással, vagyis az a standard inputról olvas ezért nem kell neki fájl.
Példa:
#include <stdio.h>
int main(int argc, char* argv[])
{
FILE* f = fopen(argv[1], "rb");
int ch;
while((ch = fgetc(f)) != EOF) putchar(ch);
fclose(f);
return 0;
}Jester
-
Jester01
veterán
C89 szabvány szerinti C nyelvben illetve C++ nyelvben csak fix méretű tömb van. C99-ben van dinamikus is. GCC meg szeret alapból nagyon laza lenni, házi feladat vagy hordozható kód esetén ajánlott a -ansi -pedantic -Wall. Ezen felül bizonyos warningok meg csak bekapcsolt optimalizáció mellett jelenkeznek.
MOD: haha a klónom gyorsabb volt Sőt tulajdonképpen mindenki. Na mindegy.
MOD #sok:
$ gcc -ansi -pedantic -Wall dab.c
dab.c: In function 'f':
dab.c:5: warning: ISO C90 forbids variable length array 'x'[ Szerkesztve ]
Jester
-
Jester01
veterán
Más konvenciók meg pont azt mondják, hogy nyugodtan használj annyi returnt amennyit akarsz, az átláthatóság miatt Ugyanis adott esetben sok if/else ág lenne illetve segédváltozók és/vagy ciklus lefutás után a feltétel újratesztelése is szükséges lehet.
int find(int needle, int* haystack, int size)
{
int result = -1;
if (haystack == NULL)
{
fputs("haystack NULL", stderr);
} else {
for(int i = 0; i < size; i++)
{
if (haystack[i] == needle)
{
result = i;
break;
}
}
}
return result;
}-vagy-
int find(int needle, int* haystack, int size)
{
if (haystack == NULL)
{
fputs("haystack NULL", stderr);
return -1;
}
for(int i = 0; i < size; i++)
{
if (haystack[i] == needle)
{
return i;
}
}
return -1;
}Az első esetben hiába van 1 return a függvény végén, ahhoz, hogy megtudd mit ad vissza ígyis-úgyis végig kell nézni a függvényt, hogy hol lesz az a változó beállítva. Akkor meg pont ugyanolyan egyszerű a return utasításokat megkeresni. Ha pedig mondjuk két ciklus van egymásbaágyazva akkor még több macera kijutni belőlük (mivel ugye goto-t sem használunk )
[ Szerkesztve ]
Jester
-
Jester01
veterán
Tipikus x86 fordító esetén a 32 bit és a 64 bit mód között csak a long más. A char, short, int, float, double az ugyanaz. Ahogy a kollega említette, a limits.h és a float.h megmondja neked a határokat. Egészeket először long-ba olvasd be az strtol függvénnyel. Itt a hibakezelés megmondja nem túl nagy-e a szám vagy van-e vele más baj. Ezután a limits.h alapján már tudod ellenőrizni belefér-e a célváltozóba. Hasonlóan a tizedestörtekre az strtod függvénnyel indulva. Szerintem
Jester
-
Jester01
veterán
válasz Sk8erPeter #1538 üzenetére
Elfelejtetted inicializálni a romai tömböt. Márpedig strcat hívása ilyen esetekben rosszat jelent. Nem ellenőrizted, hogy a scanf-nek sikerült-e beolvasni valamit egyáltalán (persze azt sem, hogy esetleg csak egy része volt értelmes a bemenetnek). Valamint hiányzik egy return 0; a végéről.
Egyébiránt pár oldallal korábban már volt itt ilyen kód
Jester
-
Jester01
veterán
válasz Sk8erPeter #1546 üzenetére
A típust merő gonoszságból direkt hagytam le, hogy legyen min gondolkodni ha valaki akar. De sajnos a te fordítód megmondja , ott van a hibaüzenetben: char* (*)[10] Ez kiolvasva azt jelenti, hogy olyan pointer ami egy tíz elemű string tömbre mutat. Vagyis gyakorlatilag a romai mátrix egy sorára. És azért adok hozzá 3-at mert visszafelé megyünk benne tehát az utolsó sorral kezdünk. Ha átrendeznénk a sorokat akkor értelemszerűen ez nem is kellene.
Jester
-
Jester01
veterán
-
Jester01
veterán
válasz Sk8erPeter #1553 üzenetére
Mindenütt számít, úgy hívják operátor precedencia. A [ ] index operátor erősebb mint a * dereferencia operátor tehát ha neked előbb kell a * akkor bizony zárójelezni kell.
char** helyiertek[10] 10 elemű tömb melynek minden eleme egy char** pointer
char* (*helyiertek)[10] 1 darab pointer ami egy 10 elemű tömbre mutat melynek elemei char* pointerek (stringek)Jester
-
Jester01
veterán
válasz LevyZidane #1560 üzenetére
Igazából a ciklusmag elején kellene foglalni mindig egy új elemet amit a végén (ha sikerült az összes mezőt beolvasni) hozzáadsz a listához.
Jester
-
Jester01
veterán
válasz grabber #1559 üzenetére
1. a main után hiányzik a zárójelpár
2. a FILE * brain után hiányzik egy pontosvessző
3. a pointerek csillagja ízlés szerint vagy a típushoz vagy a változóhoz írandó, középre semmiképp (mert úgy aztán tényleg szorzásnak néz ki - de szintaktikailag helyes)
4. ha egyszer void a main akkor nem lehet benne return(1)
5. a return nem függvényhívás nem kell oda a zárójel (de ez is helyes szintaktikailag)
6. a Grabber:\ nem tudom micsoda de bízom benne, hogy a géped tudja
7. viszont érdemes lenne azért ellenőrizni a brain pointert is, hátha mégse
8. konstans szöveg kiírásához az (f)puts ajánlott, főleg, ha nem tudod mi a szöveg
9. hibajelzéseket tipikusan az stderr kimenetre küldjük
10. a while(feof(fp)) az esetek többségében hibás struktúra, helyette az adott beolvasó függvény visszatérési értékét kell vizsgálni
11. az fgetc meglepő módon int típust ad vissza, hogy tudja jelezni a fájl végét. Tehát a c változó típusa ez legyen
12. az fwrite hívást gyanítom a fórummotor tette tönkre, tessék szépen használni a Programkód gombot (egy őstagnak magyarázzam? )
13. mindazonáltal ha fgetc van, akkor a kiíráshoz fputc ajánlott, mert az a párja
14. a kiírás sikerességét is jó ellenőrizni
15. a kimeneti fájlt nem annyira célszerű bezárni a ciklusban egyetlen karakter kiírása után#include <stdio.h>
int main()
{
FILE* fp;
FILE* brain;
int c;
fp = fopen("C:\\Tanuljunk meg programozni.txt", "rt");
brain = fopen("Grabber:\\Head\\Brain.txt", "a+t");
if (fp == NULL || brain == NULL) {
fputs("Hiba a fajlok megnyitasakor\n", stderr);
return 1;
}
while((c = fgetc(fp)) != EOF) {
if (fputc(c, brain) == EOF) {
fputs("Hiba iras kozben!\n", stderr);
fclose(brain);
fclose(fp);
return 1;
}
}
fclose(brain);
fclose(fp);
return 0;
}[ Szerkesztve ]
Jester
-
Jester01
veterán
-
Jester01
veterán
válasz Dirty_Pio #1622 üzenetére
Már az init függvényedben is van egy túlcímzés z[maxlen].next=-1; .
Az add függvényben sem "megy minden jól": if(-1==(k=z[k].next)) z[k].next=*d; Továbbá a temp változót két típusként is használod, egyszer tipnod egyszer meg tiplista. Ezeket javítva látszólag működik a kód, bár a typedef char tipcursor; igen szerencsétlen választás mivel nem tudhatod előjeles vagy nem. Márpedig ha nem az, akkor -1 sose lesz és végtelen ciklusba kerül a program.Láncolt listába beszúráskor amúgy nem kellene az elemeket másolgatni.
Jester
-
Jester01
veterán
válasz Dead_slow #1626 üzenetére
Mivel a legnagyobb különbséget már megtaláltad így semmi más dolgod nincs mint mégegyszer végigmenni a telkeken és kiírni azon telkek jellemzőit amiknél a különbség megegyezik a maximummal. (A feladatkiírás szerint több is lehet, különben elég lenne az első ciklusban egyszerűen megjegyezni az elem indexet is.)
Jester
-
Jester01
veterán
válasz Scroll Lock #1640 üzenetére
1) C-ben így nem tudsz dinamikus tömböt csinálni. Pointerekkel és malloc-kal kell játszani.
2) Nem, annak a tömbnek pontosan 1 dimenziósnak kell lennieJester
-
Jester01
veterán
válasz Gyuri16 #1677 üzenetére
Valószínűleg ez fájl felülírás, tehát már lehet valami ott. Ha feltételezzük, hogy az olvasás a fájl végéig megy, akkor 0 byte hatására még ha van is utána szemét az C stringként már nem fog látszani.
Pl. ha a fájlban most az van, hogy "makvirag" és azzal akarod felülírni, hogy "rozsa" akkor a 0 byte nélkül az lenne ott átmenetileg, hogy "rozsarag". Ha egy másik program épp ilyenkor olvasná ki akkor hibás adatot kapna. Ha viszont a lezáró nulla byte is bekerül, akkor azt fogja kapni, hogy "rozsa<0>ag". De mivel a C logika szerint a string csak a 0 byteig tart, ezért ez a helyes "rozsa" értékkel egyenértékű. Ezután persze az ftruncate le fogja vágni a fölösleges byteokat, szóval csak egy nagyon rövid ideig fordulhat elő.
Jester
-
Jester01
veterán
válasz Gyuri16 #1680 üzenetére
man waitpid
POSIX.1-2001 specifies that if the disposition of SIGCHLD is set to SIG_IGN or the SA_NOCLDWAIT flag is set for
SIGCHLD (see sigaction(2)), then children that terminate do not become zombies and a call to wait() or waitpid() will
block until all children have terminated, and then fail with errno set to ECHILD. (The original POSIX standard left
the behavior of setting SIGCHLD to SIG_IGN unspecified. Note that even though the default disposition of SIGCHLD is
"ignore", explicitly setting the disposition to SIG_IGN results in different treatment of zombie process children.)Tehát a 2001-es POSIX szabvány szerint a signal miatt nem lesznek zombik, a waitpid pedig az összes gyereket bevárja és aztán hibát dob (vagyis nem adja vissza a status-t). Más szabványú implementáció esetén még a signal ellenére is szükséges lehet a waitpid a zombik elkerülésére.
Jester
-
Jester01
veterán
válasz Sk8erPeter #1708 üzenetére
Amilyen gyorsan megtanultad, ugyanolyan gyorsan felejtsd is el
Ugyanis semmilyen hibakezelést nem végez így nagyon kiváló túlcsordulást lehet vele csinálni. Persze tehetsz bele max hosszot, de akkor meg azzal kell külön vacakolni, hogy a pufferben maradt szemetet kiolvasd (ugye a példa szerint is benne marad egy enter ami a következő beolvasást megzavarhatja) illetve hogy értelmes hibaüzenetet adj. Szóval kb házi feladat programokhoz jó, egyébként pedig egész sorokat kell olvasni és aztán szépen értelmezni. Macerás, de ez van.Jester
-
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
Jester
-
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.
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!
- Fejhallgató erősítő és DAC topik
- World of Tanks - MMO
- ASUS routerek
- Azonnali informatikai kérdések órája
- Kínai, és egyéb olcsó órák topikja
- Garmin Forerunner 165 - alapozó edzés
- Kerékpárosok, bringások ide!
- Hogy is néznek ki a gépeink?
- Apple iPhone 15 Pro Max - Attack on Titan
- Ford topik
- További aktív témák...
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen