- iPhone topik
- Honor Magic6 Pro - kör közepén számok
- Apple Watch
- Motorola Razr 60 Ultra - ez a kagyló könnyen megfő
- Motorola Edge 50 Pro - több Moto-erő kéne bele
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Apple iPhone 16 Pro - rutinvizsga
- A hagyományos (nem okos-) telefonok jelene és jövője
- Keretmentesít a Galaxy S25 FE
- Mobil flották
Új hozzászólás Aktív témák
-
Karma
félisten
A char egy -128-tól 127-ig terjedő egész szám, csak véletlen, hogy a karaktereket is ezzel írja le a paraszt a C nyelvben. Mivel belül nem tizes számrendszerben tárolja a rendszer a számokat, de még csak nem is BCD-ben, Neked kell kézzel kiszámolnod az egyes helyiértékeket. A tizes maradékos osztás csodákra képes
-
-
#1818
Karma
félisten
Sk8erPeter
#1817
Karma
félisten
válasz
Sk8erPeter
#1817
üzenetére
Fincsi feladat, tiszta nosztalgia
-
#1816
Karma
félisten
Sk8erPeter
#1815
Karma
félisten
válasz
Sk8erPeter
#1815
üzenetére
Ez egyébként ahhoz a hftestes hülyeséghez kell, nem?
Tényleg ez a megoldás, amit írtál, egy for ciklus és szevasz.
Én is így csináltam. -
Karma
félisten
válasz
Korcsii
#1789
üzenetére
Nezd meg az strcmp fuggvenyt, azzal lehet peldaul ket karakterlancot ABC szerint osszehasonlitani.
Az mar egy kicsit nagyobb magia, hogy olyan fuggvenyt irj, ami a struktura tetszoleges tagvaltozoja szerint kepes rendezni. C++-ban tudom hogy van erre megfelelo pointertipus, sima C-ben nem tudom.
-
Karma
félisten
válasz
Retekegér
#1775
üzenetére
Sajnos attól még nem lesz semmi értelme, tényleg. Én is ezt a könyvet adtam látatlanban az öcsémnek, hogy ebből összeszedheti a nyelv alapjait, de azt tapasztaltam (legalábbis a '96-os kiadásban), hogy sokszor van, hogy nem mondja el a miértet.
Jester01: De ha csak annyi a lényeg, hogy véletlenszámokat generáljunk (ami persze ebben a formában oximoron), akkor nincs semmi értelme. Én ezt feltételeztem.
-
-
Karma
félisten
válasz
Korcsii
#1739
üzenetére
A Borland és a Turbo is két antik retek, amit csak azért nyomnak az iskolákban, mert a tanárok lusták művelni magukat. Ahogy az előbb is említettem, csak DOS-ban működő móka mind a kettő.
A Dev-C++ teljesen korrekt választás, bár én annyira nem szeretem azt az IDE-t. Anno Code:
locks-ot használtam első félévben, azóta meg XCode-ot. -
Karma
félisten
-
Karma
félisten
válasz
Dead_slow
#1715
üzenetére
Azért ez üt... "mondván, hogy a név állhat simán 3 részből is".
Semmi szépet nem tudok elmondani az oktatásunk állásáról.Egyébként az lehet baj például, hogy a masodik és harmadik tömbökbe az i. helytől kezdesz el írni, így az első i-1 karakterben vagy szemét van.
Egyáltalán ezek mik? Hogy vannak deklarálva?
-
-
Karma
félisten
Egyszerű: nem törődsz a beolvasott szöveg hosszával, mindig 100 elemig fut a ciklusod. Feltéve, hogy a getline függvény jól működik (elég sok helyen írták ugyanezt a topikban, gondolom valami órai sablon), akkor a visszatérési értéke a beolvasott karakterek száma, használd ezt a ciklus végértékének.
-
Karma
félisten
válasz
Retekegér
#1631
üzenetére
Arra meg ott a printf függvény, első paraméterében megadhatod a kiírás formátumát (én pl. semmit se tudok jelenleg a tömböt elemeinek típusáról
), utána pedig a többi paraméterben a változókat adhatod meg.Pl. egy egészeket tartalmazó array nevű tömbre (l elemű), soronként egy érték:
int i;
...
for (i = 0; i < l; i++)
{
printf("%d\n", array[i]);
} -
#1543
Karma
félisten
Sk8erPeter
#1542
Karma
félisten
válasz
Sk8erPeter
#1542
üzenetére
Egy char*** a szövegek tárolására, melyet a szamjegy-gyel indexelsz (persze 0-ra redukálva) okosan, így nem kell minden egyes számjegyhez if-et írni?
-
#1506
Karma
félisten
Sk8erPeter
#1503
Karma
félisten
válasz
Sk8erPeter
#1503
üzenetére
Gyakoroltam, meg a dolgok mögé próbálok nézni sűrűn
Mondjuk nem mondanám, hogy mestere vagyok a dolgoknak, a szabványos C++-t például igencsak kimosta a Symbian belőlem
Ami egyébként mindig friss élmény, ugyanis szinte mindennap használom - egyetem mellett/egyetemen keresztül dolgozom elsősorban Symbian programozással.Egyébként MSc elsőéves vagyok, és csak azért félig, mert egyrészt sikerült ezt a félévet félvállról vennem (
), másrészt nem igazán van hangulatom az egészhez már.Apropó Symbian, célszerű elkerülni, ha az ember nem szereti a fájdalmat. Én nem voltam rá felkészülve, de hamar hozzászoktam azóta
. Az mondjuk biztos, hogy egy ilyen korlátolt és korlátozott környezetben dolgozás kialakítja az ösztönöket a korrekt memóriahasználatra például. -
#1491
Karma
félisten
Sk8erPeter
#1490
Karma
félisten
válasz
Sk8erPeter
#1490
üzenetére
Pedig ha azok a fogalmak megvannak, az első kérdésre is könnyebb válaszolni. Persze mindkettő C++ minta (sőt, a második csak és kizárólag Symbian C++-ban van), ezért C-nél még nem kavar be.
Auto pointer: egy olyan objektum, ami ha megsemmisül a stacken, magával ránt egy hozzárendelt heapen lévő objektumot is, így amikor az auto_ptr scope-on kívülre kerül, a másik objektum biztosan megsemmisül. Ez egy egyszerűsítés, így biztosan nem maradhat meg a heapen lévő objektum pl. azért, mert valahova berakott az ember még egy returnt, és elfelejtette felszabadítani ott is a memóriát
Valahogy így néz ki:
int valami()
{
int *valami_int = new int; // heapen hoztam letre, mint a malloc C-ben
auto_ptr<int> valami_ptr(valami_int); // az auto pointerre bizom a felszabaditast
...
// ugy hasznalom, mint egy pointert
*valami_ptr = 5; // a valtozo erteket valtoztatom itt
...
return 0; // valami_ptr megsemmisul -> valami_int is torlodik
...
return 1; // valahol mashol ugyanez lezajlik
}Ha nem lenne ez az auto_ptr, akkor mindkét return elé oda kéne írni explicite a következő sort (ez a free C++-os megfelelője), amit könnyen kifelejthet az ember, ha utólag hackelget bele a függvénybe, memory leaket okozva.
delete valami_int;
Cleanup Stack: Amikor a Symbiant írták, még nagyon fejletlenek voltak a C++ fordítók, kivételdobáskor a stacken lévő objektumokra nem hívódott meg a destruktor, ami mindenféle vicces hibához vezethetett, többek között "csak" memory leakhez. Ezért a nagyokosok kitalálták, hogy "csináljunk saját kivételkezelést!", megalkották a Leave-eket és a Cleanup Stacket.
Minden heapen lefoglalt objektumot, ami nem tagváltozó, fel kell kézzel rakni a CleanupStackre, és persze le is kell venni onnan, ha olyan műveletek jönnek, amik kivételt (konkrétan leave-et) dobhatnak. Tehát mindig figyelni kell a programozónak arra, hogy mikor mi van rajta, mikor melyik objektum kinek a felelősségébe tartozik, és ennek megfelelően variálni.
Na itt jön be, hogy ha több return utasítás van, akkor kitörhet a káosz, a függvény különböző részein más lehet a CleanupStack állapota, minden returnnél megfelelően adminisztrálni kell, és ha bármit változtatni kell, mindenhol át kell írni...
Példakód:
TInt CSomething::DoSomethingL()
{
TInt result = 0;
CSomethingBig *big = CSomethingBig::NewL();
CleanupStack::PushL(big);
RSomethingResource res;
CleanupClosePushL(res);
result = res->DoSomethingDangerousL(big); // ha ez dob egy leave-et, res bezarodik, big megsemmisul
CleanupStack::PopAndDestroy(2, big); // mindket elemet megsemmisiti
return result;
}Ezt a kódot nem magyaráznám túl, ha nem baj, hiszen csak random firkáltam. A lényeg az, hogy a PopAndDestroy hívást minden return előtt meg kell hívni, pontosan.
-
#1487
Karma
félisten
Sk8erPeter
#1486
Karma
félisten
válasz
Sk8erPeter
#1486
üzenetére
Eh, mondtam, hogy naív megoldás, azt nem, hogy jó is
Meg egyébként is csak firkáltam. -
-
#1479
Karma
félisten
Sk8erPeter
#1478
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;
} -
#1477
Karma
félisten
Sk8erPeter
#1476
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.
-
#1472
Karma
félisten
Darth_Revan
#1471
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?
-
#1470
Karma
félisten
Darth_Revan
#1469
Karma
félisten
válasz
Darth_Revan
#1469
üzenetére
unsigned char?
-
#1468
Karma
félisten
Darth_Revan
#1467
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]);
} -
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. -
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ő
-
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.
-
#1450
Karma
félisten
Sk8erPeter
#1447
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.
-
#1444
Karma
félisten
Sk8erPeter
#1435
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!
-
#1434
Karma
félisten
Sk8erPeter
#1433
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.
-
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.
-
#1427
Karma
félisten
Sk8erPeter
#1424
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
-
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; -
#1422
Karma
félisten
Sk8erPeter
#1420
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. -
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!
-
#1414
Karma
félisten
Sk8erPeter
#1412
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!
-
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 -
#1406
Karma
félisten
Sk8erPeter
#1405
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.
-
#1403
Karma
félisten
Sk8erPeter
#1402
Karma
félisten
válasz
Sk8erPeter
#1402
üzenetére
Van aki dolgozni is jár
![;]](//cdn.rios.hu/dl/s/v1.gif)
Mindjárt nézem...Megnéztem... Mi is a kérdés?
-
-
#1385
Karma
félisten
Sk8erPeter
#1384
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; -
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.
-
-
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.
-
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.
-
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 -
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
-
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
-
#1311
Karma
félisten
rroolleerr
#1310
Karma
félisten
válasz
rroolleerr
#1310
üzenetére
A wikipédia elég jónak tűnik ebben a témában.
-
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.
-
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.
-
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++)
{
...
} -
-
#1281
Karma
félisten
m0h0senator
#1280
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);
locks/Dev-C++/VS Express/akármiért se kell fizetni.
Ami egyébként mindig friss élmény, ugyanis szinte mindennap használom - egyetem mellett/egyetemen keresztül dolgozom elsősorban Symbian programozással.
), másrészt nem igazán van hangulatom az egészhez már.
. Az mondjuk biztos, hogy egy ilyen korlátolt és korlátozott környezetben dolgozás kialakítja az ösztönöket a korrekt memóriahasználatra például.
, csak belejavítottam.
Akkora lett a fejem hogy csak na...
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Mindjárt nézem...
Ú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!
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- Bomba ár! Fujitsu LifeBook U758 - i5-8GEN I 8GB I 256GB SSD I HDMI I 15,6" FHD I W11 I Garancia!
- BESZÁMÍTÁS! Asus TUF B550M R7 5700X 16GB DDR4 512GB SSD RTX 3060 Ti 8GB Rampage SHIVA FSP 700W
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RTX 4070Ti Super GAMER PC termékbeszámítás
- AKCIÓ! ASUS STRIX B650E-E R7 7700 64GB DDR5 1TB SSD RTX 3080 10GB Thermaltake Ceres 500 850W
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged