Új hozzászólás Aktív témák
-
Karma
félisten
válasz m0h0senator #1280 üzenetére
Húha. Légyszi használd a Kód gombot, és úgy illeszd be a kódot, lehetőleg indentálva, mert ez így elég nehezen olvasható.
Elöljáróban: Egyszerűbb lenne egy for ciklus 2-től 100-ig (gyakorlatilag most is ez van, csak while-lal), és minden esetben végezni egy prímtesztet. Most is ezt akarnád csinálni, csak olyan kusza, hogy nem látszik.
A hiba nagyon valószínű, hogy azért van, mert elfelejtetted alaphelyzetbe állítani az oszto és a prim változókat a ciklusmagban.
OMG! Megvan, hogy miért 854! Mert pointert íratsz ki, nem a számot!
printf("%i ", x);
[ Szerkesztve ]
“All nothings are not equal.”
-
Karma
félisten
Nos, a ciklusmagot és a kiírást kijavítva nálam már jól működik.
iMac:Debug zsolt$ ./test
2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79 83 89 97Azért nem lenne hátrány, ha azokat a while ciklusokat újragondolnád
[ Szerkesztve ]
“All nothings are not equal.”
-
Karma
félisten
válasz Daneeka #1283 üzenetére
Nálam működik (XCode, OSX 10.6). Nem lehet, hogy egyszerűen kicsúszik a 2-es a képből? (a szabvány Windowsos terminál pont 25 soros), amit hajnalok hajnalán nem vettél észre?
Mi ez a nagy while mánia egyébként? Miért nem lehet for ciklust használni? Meg indentálni?
for (i = 1; i <= 50; i++)
{
...
}[ Szerkesztve ]
“All nothings are not equal.”
-
Karma
félisten
Pl. úgy, hogy nem intet használsz, hanem longot, ami mindig 32-bites.
Aki kitalálta azt, hogy: 1) intet kell használni, valamint 2) ezt kikiáltja C++ programozásnak, pedig ez csak egy C program, C++ fordítóval lefordítva, azt (hmm)... Nem illik azt mondani, hogy tarkón kéne lőni, úgyhogy csak tarkón kéne vágni.
“All nothings are not equal.”
-
Karma
félisten
válasz Jester01 #1296 üzenetére
"Mindig? Na ne viccelj!"
Bakker, és tényleg igazad van. "At least"... Mindegy, azt a problémát megoldja, hogy kevesebb nem lehet
"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. "
Meg lehet írni, de szerintem ilyen kitételek mellett (és hallgatói felkészültség mellett) nem ez a cél.
“All nothings are not equal.”
-
Karma
félisten
válasz rroolleerr #1310 üzenetére
A wikipédia elég jónak tűnik ebben a témában.
“All nothings are not equal.”
-
Karma
félisten
Ilyesmi. Ha VAGY-nál amint igazat talál, abbahagyja a kiértékelést, ÉS-nél meg amint hamisat. Elvileg ha a & és a | operátorokat használod, akkor nincsen ilyen egyszerűsítés.
A gondolatkísérleted pontosan így zajlik le, ha a második tagban mellékhatással járó utasítás van, akkor az nem fog lefutni. Többek között ezért se illik feltételbe mellékhatást tenni
“All nothings are not equal.”
-
Karma
félisten
Na ezért jó egy jó IDE
Parancssorban esetleg egy kis gdb-zéssel ki lehetne deríteni. De van egy favágóbb módszer: írj a konzolraEgyébként akkor is szokott segfault jönni (OpenInkpotos tapasztalat), hogyha grafikus programot akarnál futtatni, és nincs jól megadva a DISPLAY környezeti változó, így nem tud az X-hez csatlakozni.
Gyuri16: Pont kiszerkesztettem a hozzászólásomból a strace-et
[ Szerkesztve ]
“All nothings are not equal.”
-
Karma
félisten
válasz cellpeti #1330 üzenetére
Mondjuk csinálhatod úgy, ha már do-while-t akarsz használni, hogy az ok változódat használod fel. A többi részhez nem nyúlok:
do
{
int ok = 0;
printf("Kérem az előnevezettek számát: \n");
if(!getline(elonev,25))
{
printf("Üres sort adtal meg!\n");
}
else
{
ok = 1;
}
while (!ok);Magyarán addig teszi fel a kérdést, amíg nem kap egy nem-üres sort. Nem ártana azért 1-be állítás előtt ellenőrizni, hogy számot kapott-e (fontosabb mint az üres sor, nomeg összefügg ).
UI: Mit akarnak ezek tömbbe?! Nincs ebben semmilyen tömbben tárolható adat
“All nothings are not equal.”
-
Karma
félisten
válasz cellpeti #1341 üzenetére
Az a szitu, hogy a getline, mint olyan, egy nem szabványos függvény. Míg Windowson a környezetedben nem volt benne (mert minek?), az Ubuntuban lévő glib-ben benne van, és ez összeütközik a forráskódodban lévővel. Ezt nem tudod megkerülni, csak ha más nevet adsz neki
Nincs ebben semmi varázslat, csak hackelő tanárok. Ja és tanulj meg angolul. Komolyan.
[ Szerkesztve ]
“All nothings are not equal.”
-
Karma
félisten
válasz cellpeti #1352 üzenetére
Kilépéshez használd az exit(0) függvényt
Egyébként van egy teljesen felesleges rész: a nume-t és az atoi-t simán összevonhatod egy sscanf hívásba, amivel két legyet ütsz egy csapásra: ha nem szám, akkor 0-t ad vissza (megvan a hibadetektálás), ha szám, akkor meg 1-et, és a paraméterben átadott változóban ott lesz az érték. A használatára itt egy egyszerű példa.
[ Szerkesztve ]
“All nothings are not equal.”
-
Karma
félisten
-
-
Karma
félisten
A pointer mérete is fix 32 bites architektúrán 32 bit például.
Szerintem arra céloztak anno a hasonlósággal, hogy a subscript operátor valójában ekvivalens egy kis pointeraritmetikával.
int array[5];
int* pointer = array;
array[5] === pointer[5] === *(pointer+5) // ekvivalensekDe most hogy nézem, rájöttem a különbségre is: míg a pointer szabadon módosítható, a tömbváltozó nem, konstans értéke van.
“All nothings are not equal.”
-
Karma
félisten
válasz Sk8erPeter #1384 üzenetére
A tömbváltozó alatt én az "array"-t értettem, ami gyakorlatilag egy pointer az első elemre. Ez a konstans, nem lehet elállítani onnan, ellentétben egy pointerrel.
Tehát nem lehet olyat mondani, hogy
array = pointer + 1;[ Szerkesztve ]
“All nothings are not equal.”
-
Karma
félisten
válasz cellpeti #1388 üzenetére
De lehet, csak az Alt+G-n már van egy másik shortcut A beállítások között ki kell törölni. Úgy emlékeztem, hogy csak a Dev C++-ban van ilyen szívás...
Szerintem egyébként az angol billentyűkiosztás sokkal jobb a kódoláshoz, a Windows magyarja nagyon gáz
“All nothings are not equal.”
-
Karma
félisten
válasz Sk8erPeter #1402 üzenetére
Van aki dolgozni is jár Mindjárt nézem...
Megnéztem... Mi is a kérdés?
[ Szerkesztve ]
“All nothings are not equal.”
-
Karma
félisten
válasz Sk8erPeter #1405 üzenetére
Félreértelmezted a második példát, ott sincs szó átméretezésről, egyszerűen egy tömbök tömbje szerkezetben foglalgat memóriát. Az első példára is igaz az viszont, hogy átméretezni pusztán malloc-kal nem lehet egy már lefoglalt tömböt. A realloc-kal hamarabb (realloc = malloc + memcpy + free egyben).
Az eredeti üzenet meg a fix szélességű stack/globális tömbökről szólt, nem a heapen lévőkről. Azokat tényleg nem tudod változtatni, se dinamikusan kiszabni, erre elég jó volt a kétsoros példakód.
“All nothings are not equal.”
-
Karma
félisten
válasz Vasinger! #1407 üzenetére
Középre zárni úgy kell, hogy fogod a szöveged hosszát, elosztod kettővel, kivonod a képernyő szélességéből, és a kapott számszor kiírsz egy szóközt. De most ezzel asszem lelőttem a poént.
Egyébként meg egyszerű: a \t\n\a nem az, mint amit Te az előbb leírtál
Ez most egy tab, utána egy sortörés, végül csilingelés. Hasonlítsd össze“All nothings are not equal.”
-
Karma
félisten
válasz Sk8erPeter #1412 üzenetére
"A double *ujtomb; sorban tehát deklarálunk egy pointerváltozót ujtomb néven, aminek csak később foglaljuk le a szükséges memóriát, először még csak meghatározzuk, hogy "lesz ilyen"."
Igen. Bár ha nagyon szőrözni akarnék, ahogy egyszer már tettem, a megfogalmazás nem tökéletes: magát a pointert sikeresen definiáltuk, 4 byte-ot kapott a stacken (vagy globálisan), mint egy átlagos változó. De ezt most felejtsük el egy pillanatra, mert irreleváns.
"Amikor megtudtuk az eredeti tömb számunkra szükséges elemeit megszámolva, mekkora új tömbre van szükségünk, azután lefoglaltuk neki a számára szükséges memóriát. Ezután tömbként és egyben pointerként használtuk fel a későbbiekben, rakosgattunk bele elemeket, és itt ez most kicsit zavaros számomra, hogy akkor most melyik fogalmat is használjuk, ami helytálló. Mert tömbnek foglalunk helyet, de pointertömb... "
Nem, mi csak és kizárólag pointerként használtuk, nincs külön olyan, hogy "tömbként" használni. Ez a szép a C-ben (konkrét és ironikus értelemben is), hogy ilyen egyszerű Mint írtam korábban, a p[n] subscript operátor az ekvivalens a *(p+n) művelettel.
A pointertömb egy teljesen más fogalom. Pl. int **valami; egy int pointerre mutató pointer, amivel (hasonlóan a második példakódhoz) tömbök tömbjét lehet megvalósítani. Ugyanezt lehet fix méretben is: int valami[5][2];.
"Ráadásul - bocsi az értetlenkedésért, csak vannak ilyen homályos pontok - akkor a memóriafoglalással ezek szerint nem "méretezünk", hanem nem tudom, mit csinálunk "
A memóriafoglalással memóriát foglalunk
"És még egy pluszkérdés: a main()-ben free-vel felszabadítjuk a memóriát, de ekkor nem "szabadulunk meg" egyben az adatszerkezet már korábban eltárolt értékeitől is?"
Dehogynem. Amire meghívod a free-t, az felszabadul, az értékei érvénytelenné és elérhetetlenné válnak. (Legalábbis így kell bánni vele, ha nem akarsz bugzani.)
Fontos megjegyezni, hogy egy dinamikus pointertömbnél az alstruktúrákat egyesével fel kell szabadítani, a fordító nem fogja kibogozni!
“All nothings are not equal.”
-
Karma
félisten
"de ugye ez csak byteoknal mukodne ilyen egyszeuen. Int-nel mar bonyolultabb a tema. Ott a kovetkezo egyenloseg igaz: p[5] = *(p+sizeof(int)*5)"
Nem igaz!
Ha a p ebben a példában egy int*, akkor automatikusan egy egész értéknyit lép előre, nem kell és nem szabad a sizeoffal varázsolni benne! Tehát 32 biten "p+1" az 32 bittel előrébb mutat, nem csak egy bájttal!
[ Szerkesztve ]
“All nothings are not equal.”
-
Karma
félisten
válasz Sk8erPeter #1420 üzenetére
"És hogy is van tovább? "
Igazából nincs itt sok már, csak azért tereltem el a szót, hogy ne legyen kavar.
A pointer a háttérben mindig egy 32/64 bites int szám, egyszerű változó, és úgy is viselkedik, mintha egy sima int változód lenne."Mondjuk jelen esetben a példaprogramnál ez nem volt világos, hogy minek foglaltunk akkor helyet az adatoknak, ha utána rögtön az eltárolás után meg is szabadultunk tőle. Igaz, erre lehetne azt mondani, hogy mivel nem volt része a feladatnak az, hogy tovább tárolgassuk, és még csináljunk vele valamit, csak a szavakra darabolás."
Pontosan ez történt Felépíti, és el is tünteti. Szerintem durva pontlevonás járna érte, ha nem tenné a hallgató. Viszont cserébe jól bemutatja, hogy egy fésűs adatszerkezetet hogy kell felszabadítani.
“All nothings are not equal.”
-
Karma
félisten
Pfff, az előbb a fórummotor kidobta a szerkesztésemet a kukába...
Szóval az általad említett problémának van egy alternatív megoldása, ha az adott környezet úgy kívánja meg (szerencsére a legtöbbet ilyenben dolgozok, én a típushoz szeretem kötni a *-ot és a &-et ):
int* first;
int* second;“All nothings are not equal.”
-
Karma
félisten
válasz Sk8erPeter #1424 üzenetére
Ezért fésűs (a nyilak a pointereket jelölik):
Egy kicsit elrontottam a képet, minden szó végén ott van még egy 0 is, lezárva a szavakat. A függőleges oszlopban meg csak akkor vannak 0-k, ha calloc-kal lett lefoglalva, vagy kézzel ki lett előre nullázva. De sajnos Excelben rajzoltam, és becsuktam a doksit
[ Szerkesztve ]
“All nothings are not equal.”
-
Karma
félisten
Nem azért mondom (nem is tudom, van külön C++ topik is?), mindössze az, hogy ez tényleg sokkal körülményesebb C-ben. Egyébként én meg (Symbian) a HookLoggert szoktam használni, ha memory leakre vadászom: a saját kódom módosítása nélkül végzi el ugyanezt, amit Te az előbb manuális módszerként leírtál. (Rendszerszinten áll rá az Alloc/Free-re).
Linuxon és tsa. másik alternatíva lehet még a Valgrind is.
“All nothings are not equal.”
-
Karma
félisten
válasz Sk8erPeter #1433 üzenetére
Nem nekem szól a kérdés, de azért van pár ötletem:
1) Méretet átadni stack/statikus tömböknél redundáns információ (sizeof() megmondja).
2) Egyébként is, ezt a "belső" információt kívülről átadni csak még egy hibaforrás.
3) A \0 karaktertömböknél elmegy (bár nem 100%-os biztonság), pointertömböknél már körülményesebb (mi van, ha nincs tele a tömb? Mivel töltöd fel?), egyéb tömböknél meg teljesen megvalósíthatatlan önmagában.Az igazi megoldás tényleg a tömbosztályok használata, de osztályok (szintaktikailag) csak a C++-ban vannak. Szemantikailag viszont megoldható C-ben is egy kis gondolkodással: struktúrával és az azt manipuláló függvényekkel - bár szerintem nem találom fel a spanyolviaszt, biztosan más már írt ilyet.
“All nothings are not equal.”
-
Karma
félisten
válasz Sk8erPeter #1435 üzenetére
Hát nem tudom, oktatnak érdekes dolgokat Mondjuk production kódot még nem írtam/láttam sima C-ben, lehet hogy tényleg van ilyen konvenció.
De nem esküdnék meg rá. Nemrég láttam, hogy valahol a BME-n is goto-val tanítják a Pascalt! Akkora lett a fejem hogy csak na...
Egyébként az, hogy végigiterálsz a tömbön, még nem jelenti azt, hogy iterátorral dolgoznál. Az iterátor egy objektum-orientált minta. Röviden: ahelyett, hogy ismerned kéne a tömb/lista/stream/kismacska belső szerkezetét, és ezt figyelembe véve temérdek kódot generálnál, kérsz a kollekciótól egy iterátort, egy általános interfészt megvalósító objektumot, aminek ilyen műveletei vannak tipikusan: hasNext(), next(), removeCurrent(), satöbbi. Így szerkezettől független kódot tudsz írni
A szempontod egyébként jogos, de most hogy leírtam az előző blokkot leesett, hogy igazából miért is jobb kézzel átadni a hosszt kívülről: ezzel egységesen lehet kezelni a fix méretű és a heapen lévő tömböket is!
“All nothings are not equal.”
-
Karma
félisten
válasz Sk8erPeter #1447 üzenetére
Tudom hogy VIK-en mi a helyzet, én is informatikus-hallgató vagyok (félig) Viszont egy másik fórumozónak segítettem Pascalban, és ő másolt be órai kódot, ami hemzsegett tőle. Nem mondta el, melyik szak, én részemről GTK-ra tippelnék, vagy TTK-ra.
Nem hibás elképzelés! Sőt, mint írtam az üzenetem végén, ha egységesen akarod kezelni a stacken, globálisan és a heapen lévő tömböket, akkor nincs is nagyon más lehetőséged rá. Hacsak nem varázsolsz struktúrákkal, és írsz OO kódot nyers C-ben. Good stuff. Szóval teljesen jó.
Egyszerűen, ahogy 3man is mondta, amit nem Neked kell karbantartanod, az nem lesz hibalehetőség később. A KISS ("Keep It Simple, Stupid!") filozófia általában jó eredményeket hoz.
Értettem mire gondolsz az iterátor szóval , csak belejavítottam.
Apropó goto. Igazából a dolog kettős. Van olyan helyzet (főleg C-ben, meg ahogy kovsol is írja, assemblyben végképp), amikor előnyös a használata. Például hibakezelésre kivételek helyett, vagy brutálisan mély feltételeket szétbontani (Linux kernelben láttam most rá egy példát, amikor az előbb rákerestem). Viszont nem arra való, hogy a program teljes logikáját ezzel írja meg az ember, mint amit az említett órán csináltak ("ha a user 1-et ír be, kezdjük elölről a programot" jellegű varázs). Itt van róla egy hosszú, de annál érdekesebb leírás.
“All nothings are not equal.”
-
Karma
félisten
válasz grabber #1451 üzenetére
Hát hasonlítsd össze a két kódot, elég jól látszik, a hibaüzenetek is beszédesek.
Pl.:
1) A File és a FILE két külön dolog (ez nem Pascal, a kis- és nagybetű számít!). Az utóbbi az érvényes, az előző meg a C számára ismeretlen fogalom, reklamál is miatta.
2) Ugyanebben a sorban kihagytál egy pontosvesszőt.
3) A legelső include-odat elírtad, "inlude" lett helyette, ez adja a többi hibaüzenet nagy részét.
4) A fájl elérési útvonalában nem jól írtad a \ jeleket. Mivel az escape karaktereket is az jelzi, a backslasheket kétszer kell beírni, mint a példádban.Azt hiszem ennyi az össz hiba.
“All nothings are not equal.”
-
Karma
félisten
válasz dabadab #1457 üzenetére
Az RVCT nekem mindig rinyál.
Egyébként nem úgy volt, hogy stacken tömböt csak fix méretben lehet létrehozni? Még én is ezt állítottam nemrég, de ez a sor (bár felrobbant, ha futtatja az ember) elbizonytalanított egy kicsit a hitemben. Vagy az csak a Pascalban volt így, és valamiért összekeverem? Égő
[ Szerkesztve ]
“All nothings are not equal.”
-
Karma
félisten
Áááháá! Megvan! Nem vagyok teljesen up-to-date, a C99 szabvány engedi a változó hosszúságú tömböt is stacken, ha a blokk elején ismert a hossz, tehát pl. egy függvény paramétere a tömb mérete.
float read_and_process(int sz)
{
float vals[sz]; // VLA, size determined at runtime
for (int i = 0; i < sz; i++)
vals[i] = read_value();
return process(vals, sz);
}#1460: Wikipédián találtam Elnézve a C99 újításait, gyanúsan C89-et "oktatott" anno Poppe prog1 órán.
[ Szerkesztve ]
“All nothings are not equal.”
-
Karma
félisten
válasz Darth_Revan #1467 üzenetére
Hát az biztos, hogy nem az & operátorral, ami visszaadja az adott változó címét, jelen esetben a tömböd első elemére mutató konstans pointer címét
Helyette, amikor kiírsz, csináld ezt például:
for (int i = 0; i < szam; i++)
{
putchar(tomb[i]);
}“All nothings are not equal.”
-
Karma
félisten
-
Karma
félisten
válasz Darth_Revan #1471 üzenetére
Na, ha ezt mondtad volna először, mindjárt lenne a helyzet.
Akkor meg tárold el a simán a karaktereket, és majd később sscanf-fel konvertáld őket számmá, ha számolni is kell velük. Nem jó így? Mi is lesz belőle a végén?
“All nothings are not equal.”
-
Karma
félisten
válasz Sk8erPeter #1476 üzenetére
Az exit tényleg durva. De ha már ott tartunk, számomra bevált az a gyakorlat, és egyébként is rengeteg konvenció azt is mondja, hogy a függvényeknek csak egyetlen returnje legyen, pont az átláthatóság miatt.
Egyszerűbb, ha az ember felelősségekkel tervez. Egy számot ellenörző függvénynek köze sincs a teljes program futásához (jó esetben, retardált feladatokat leszámítva), így oda értelemszerűen nem kerülhet exit. Igazából az alkalmazáslogikának 99%-ának semmi köze hozzá.
Ő "tanított", de nem programozni, hanem csak ledarálta a C nyelv alapjait. Szerencsémre az elv már korábban megvolt, Pascalban elég sokat versenyeztem, így a C nem volt nagy falat. Elővizsgával simán lenyomtam elsőre, meg általában a többi programozási tárgyat is.
[ Szerkesztve ]
“All nothings are not equal.”
-
Karma
félisten
válasz Sk8erPeter #1478 üzenetére
Egy prímtesztelőnél vannak bonyolultabb függvények is
De ezt is meg lehet oldani egy returnnel.Itt egy nagyon naív példa:
int isPrime(int aNumber)
{
int result = 1; // T.F.H. igaz
int i;
int max = aNumber / 2;
for (i = 2; i <= max && result; i++) // kilépünk a ciklusból, ha a feltevés sérül
{
result = aNumber % i;
}
return result;
}[ Szerkesztve ]
“All nothings are not equal.”
Ú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!