Hirdetés
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- GoodSpeed: Egy bihari a Hajdúságban
- Brogyi: CTEK akkumulátor töltő és másolatai
- Luck Dragon: Asszociációs játék. :)
- Parci: Milyen mosógépet vegyek?
- sziku69: Fűzzük össze a szavakat :)
- Gurulunk, WAZE?!
- Magga: PLEX: multimédia az egész lakásban
- laskr99: DFI és DFI Lanparty gyűjteményem
- bambano: Bambanő háza tája
Új hozzászólás Aktív témák
-
shev7
veterán
válasz
#90999040
#2483
üzenetére
ha egy byte-ot olvas akkor mukodni fog:
"fread Return Value: The total number of elements successfully read is returned as a size_t object, which is an integral data type. If this number differs from the count parameter, either an error occured or the End Of File was reached."
Ergo ha csak egy byte-ot olvas akkor a visszateresi ertek 0 vagy 1. Bar teny, hogy akkor is lehet 0 a visszateresi ertek ha nem erte el a file veget de valami hiba tortent. De azokat az eseteket mi sem kezeltuk le.
-
shev7
veterán
válasz
#90999040
#2478
üzenetére
Ez tuti jo? Marmint a hoszt szerintem nem jol szamolja, es az utolso karaktert sem fogja kiirni.
A reference szerint is inkabb igy kene:
FILE * pFile;
long n = 0;
pFile = fopen ("myfile.txt","rb");
if (pFile==NULL) perror ("Error opening file");
else
{
while (!feof(pFile)) {
fgetc (pFile);
n++;
}
fclose (pFile);
printf ("Total number of bytes: %d\n", n-1);
}
return 0; -
shev7
veterán
válasz
cellpeti
#2034
üzenetére
szerintem ez egy novekvobe rendezo algoritmus.
Mukodese egyszeru: ahogy a kulso for ciklus vegighalad az elemeken az aktualisan vizsgalt elem elott a tomb mar rendezett.
A belso ciklus a kulso ciklus aktualis elemetol kezdve egy minimum keresest hajt vegre. Ha talal egy elemet ami kisebb mint az i. elem akkor megcsereli oket ( a g valtozot ne keverd ide, az csak egy segedvaltozo a cserehez) es innentol kezdve ahhoz fog hasonlitani. Tehat miutan a belso for ciklus lefutott az i. elem mindig a tomb hatralevo reszenek legkisebb eleme lesz.
Ez megmagyarazza azt is, hogy miert csak az utolso elotti elemig (n-2 ig) megy a kulso forciklus. Amikor i = n-2 akkor a tomb 0 - (n-3) - ig novekvobe rendezett. A belso ciklus lefutasa utan (n-2) - be bekerul a ket utolso elem kozul a kisebb, tehat az egesz tomb rendezett. (Mas szoval: egy elemet nincs ertelme rendezeni, egy elem mindig rendezett)
-
shev7
veterán
válasz
Sk8erPeter
#1993
üzenetére
"Mondjuk az azért mókás, hogy sokszor előfordul, hogy jó darabig senki nem ír választ egy kezdő kérdésre, viszont ha valaki ad egy lehetséges gyorsmegoldást, akkor arra hirtelen mindenki rárepül, mint a dögkeselyűk. "
Mert egy majdnem jo megoldast konnyebb kijavitani, mint leirni az egeszet, tulsagosan lusta vagyok

-
shev7
veterán
válasz
Sk8erPeter
#1985
üzenetére
for(i=0;i<strlen(tomb1) && i<strlen(tomb2); i++)
{
if(tomb2[i] != '\t' || tomb2[i] != ' ')
tomb1[i]=tomb2[i];
}kerdes: mi lesz a tomb1 4. eleme, ha a tomb2 4. eleme szokoz volt

ket index kell, az egyikkel tomb1-et indexeled, a masikkal tomb2-t.
illetve ezekkel a feltetelekkel mindig bajban vagyok en is de szerintem ez nem jo. && kene || helyett, nem? Mert ez a feltetel mindig igaz.
-
shev7
veterán
válasz
Sk8erPeter
#1817
üzenetére
Hat determinisztikus allapotautomatat nem annyira nehez rajzolni hozza. Ha az megvan onnan nem nehez. De nem lovom le a poent

-
-
shev7
veterán
válasz
Korcsii
#1793
üzenetére
"függvény talán azért lenne szerencsésebb, mert 3x kell használni, és így elég lenne egyszer megírni... de igazán semmi ötletem nincs erre, max az, hogy egy sima váltózóból kap egy értéket, és azt megvizsgálva a megfelelőt pörgeti végig... na de ez lehet még hosszabb/rosszabb, mint ha mindenhova odaírnám..."
Ezt csak en nem ertem mit akar jelenteni?

-
-
-
shev7
veterán
válasz
Sk8erPeter
#1671
üzenetére
"Vagy csak én vagyok a maradi, hogy meg szoktam köszönni, ha segítenek nekem?"
Mit koszonjon meg? Nem latod, hogy nem mukodik neki

lepj tul ezen
te vagy azon keves lelkesek egyike akik jofejsegbol ingyen megcsinaljak mas hazijat. Majd megunod, en is meguntam. De addig meg ne hagyd hogy ilyenek eltantoritsanak, ha jol tudom te is meg csak tanulod a dolgokat, jo gyakorlas ez. Mi meg majd szetszedjuk, es abbol is tanul mindenki aki a topicot latogatja. Savazas nem lesz, abban biztos lehetsz! -
shev7
veterán
válasz
Sk8erPeter
#1666
üzenetére
"Már kezdem bánni, hogy megcsináltam a programot a srác helyett... "
azt sose band. Es a kritikat se vedd szemelyes sertesnek. A cel nem az, hogy megmutassuk rossz amit irtal, egyaltalan nem. A cel az, hogy mas is tanuljon belole.
-
shev7
veterán
válasz
Sk8erPeter
#1663
üzenetére
teny, hogy feleslegesen nem fut a ciklusod de a divider valtozo behozasa a kepbe csak feleslegesen bonyolitja az algoritmust, es rontja az olvashatosagot, (nekem legalabbis beletelt par percbe mig felfogtam, hogy mi van, es miert is mukodik jol) Ha valami uzenetet akar kiirni, ahhoz nem kell ez a varazslas, megy az a return elott is.
-
-
shev7
veterán
válasz
Sk8erPeter
#1591
üzenetére
nem veletlen az a break a while cikluson belul... ha a es b ket vegtelen hosszu egyforma string akkor tenyleg vegtelen ciklus lesz...
-
shev7
veterán
válasz
Sk8erPeter
#1420
üzenetére
mert ha egytol indexelnenk, akkor
p[1] = *p
p[2]= *(p+1)
.
.
.0-s indexelesnel mindket oldalon ugyan az a szam van

"hogy lehet deklarálni úgy egy változót, hogy byte *p; . Ez mire jó ebben a formában? "
Na most ennek utananeztem, hogy ne irjak hulyeseget. A lenyege, hogy egyertelmu legyen. A * operator ugyanis jobbra kot. Barmennyire is irod kozel a tipushoz

Szoval ha irsz egy ilyet:
long* first, second;
akkor deklaraltal egy long pointert (first) es egy long valtozot (second). De akkor mar miert nem irnad le egyertelmuen:
long *first, second; es igy senki nem fogja azt gondolni hogy ket pointert deklaraltal.
-
shev7
veterán
válasz
Sk8erPeter
#1412
üzenetére
bar nem nekem szol a kerdes probalok valaszolni, ha mar itt vagyok:
"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"."
Lenyegeben igen.
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.
Inkabb nevezzuk memoriateruletnek, de igen.
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...
Na itt kezdodik a fogalomzavar. Eloszor is ne hivd pointertombnek mert az nem az. A pointertom az szamomra a pointerek tombjet jelenti, es itt nem errol van szo. Hogy mi is tortenik ahhoz egy kis magyarazat.
Vegyunk eloszor egy egyszeru byte pointert: byte *p;
a p valtozo tartalma egy memoria cim. A *p ahogy a deklaraciobol is olvashato egy byteot jelent (vagyis a p pointer altal mutatott erteket). Ha tovabbmegyunk a *(p+1) - a p memoriaterulet utani byte-on levo byte-ot jelenti. Na es most jon a turpissag, maradjatok meg velem
hogy ne legyen olyan bonyolult az elet, behoztak ezt a tomb pointer megfeleltetest. (illetve nem behoztak, eddig is igy mukodott, csak mivel korabban nem voltak pointerek, nem foglalkoztunk a problemaval) Azaz a p[5] az megegyezik azzal mintha azt irnad hogy *(p+5).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)
Namost mivel ez alapbol igy mukodott tomboknel, ( ha deklaralsz egy olyat hogy
int tomb[100]; akkor a tomb igy magaban egy pointer, es a hatterben pont egy ilyen konverzio zajlik le) akkor a pointerek bevezetesevel csak annyi tortent, hogy ez "mukodik a masik iranyba is"MOD: ja es ezert indexeljuk 0-tol a tomboket C-ben

-
shev7
veterán
válasz
Sk8erPeter
#1399
üzenetére
de pont errol beszeltem. Az ujtomb valtozo nem egy "statikus" tomb. Az egy pointer. Amirol mit is irtam? Ja tenyleg, azt hogy futasi idoben lehet neki memoriat foglalni.
Tehat megegszer, mert ugy tunik nem jon at

ha egy valtozot igy deklaralsz
int *tomb
az egy pointer lesz. Ponternek futasi idoben foglasz meretet, ujra foglalod stb...
ha egy valtozot igy deklaralsz:
int tomb[100]
az egy tomb, array, nevezzuk akarminek, lesz. A pointernek foglalt terulettel ellentetben ennek a memoriaigenye mar forditaskor eldol, es a stack-en fog csucsulni megvaltoztathatatlanul, es nem a heap-en ahogy a pointer altal foglalt terulet, amivel azt csinalsz amit akarsz, lefoglalod, felszabaditod, ujrafoglalod.
Ertem?

-
shev7
veterán
válasz
Sk8erPeter
#1384
üzenetére
"ezt sem értem, mert dinamikusan is, futásidőben is lehet memóriát foglalni tömbnek, attól függően, hogy mondjuk mekkora egy másik tömb, aminek az elemeit át szeretnénk másolni egy új tömbbe, attól függően módosítjuk a foglalt memóriaméretet."
En ugy tudom, hogy tombre ilyet nem lehet. Ha azt mondom, hogy int x[5] akkor az elete vegeig 5 elemu tomb lesz. Sot en ugy tudom standard C-ben olyan sincs hogy
f(int x){
int array[x];
}Ellenben ha fogsz egy pointert akkor a pointerrel akkora teruletet foglalsz le amekkorat akarsz, es futasi idoben ugy varialod ahogy akarod.
Es a memoriakezelesrol:
Ha a tombodet nem globalis valtozokent deklaralod, akkor a tombnek a helyet a stack-en foglalja le. Ugyan ez igaz a pointer-re is, tehat a pointer altal mutatott cim is a stack-en lesz. Ellenben, ha a pointer-hez allokalsz memoriateruletet, azt mar a heap-en fogja lefoglalni. -
shev7
veterán
válasz
Sk8erPeter
#1377
üzenetére
tomb merete fix

-
-
shev7
veterán
utananeztem a perrornak, es ahogy nezem ennek az a lenyege, hogy egy globalis valtozo tarolja, hogy a program futtatasa soran milyen hiba lepett fel, es a parameterul adott string utan kiirja. Tehat teszem azt, ha az atoi-t ugy probalnad meghivni, hogy elotte nem ellenorzod le hogy konvertalhato-e szamma a string, akkor ha hiba tortent, beallitana az errno nevu globalis valtozot (hivas elott erdemes nullazni, es includolni kell az errno.h-t) Ha az atoi hivas utan ellenorzod, hogy az errno erteke 0. Ha nem, akkor hivsz egy perror-t ami kirna a szoveget, meg az errno hibakodnak megfelelo szoveget. De mivel te mindig leellenorzod, hogy a szam konvertalhato-e, a program futasa soran sosem kap rossz parametert, sosem fog az errno erteke megvaltozni, ezert a perror hivas ebbol a szempontbol felesleges, irhatnal egybol a stderr-re is.
Visszaterve a temara: mivel fogalmam sincs mi az ami Kernighan-Ritchie C es mi az ami nem, fogalmam sincs mi a baja. De ha perror-t lehet hasznalni Kernighan-Ritchie C-ben, akkor lehet, hogy arra gondol a tanero amit fennt levezettem mert akkor az lehet hogy Kernighan-Ritchie-sebb

-
shev7
veterán
válasz
feherpeter
#223
üzenetére
nem ertem a felhaborodasodat... adtam linket, vagy nem?
-
shev7
veterán
válasz
feherpeter
#221
üzenetére
google-t ismered?

-
shev7
veterán
válasz
feherpeter
#217
üzenetére
at kell konvertalnod az int-et char*-ba. Mivel ez relative gyakori muvelet van ra konyvtari fv. itoa a baratod.
Ú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!
- Latitude 7450 14" QHD+ IPS érintő Ultra 7 165U 32GB 512GB NVMe ujjolv IR kam gar
- AKCIÓ! ÚJ! GAMER PC - RTX 5060 8GB - i5 12400F/14400F - 16GB DDR4 - 500GB Nvme SSD
- Lenovo Legion 9 16" 3.2K Mini LED Laptop! i9-13980HX / RTX 4090 / 32GB DDR5 / 2TB NVMe! BeszámítOK
- TUF Gaming F15 FX506HC 15.6" FHD IPS i5-11400H RTX 3050 16GB 512GB NVMe magyar vbill gar
- BONTATLAN Új iPhone 17 PRO MAX Silver - Ezüst 256-512GGB Független 1év Apple G Azonnal átvehető.Deák
- Telefon felvásárlás!! iPhone 16/iPhone 16 Plus/iPhone 16 Pro/iPhone 16 Pro Max
- 120 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 7 7745HX, RTX 4070 (ELKELT)
- HP Omen 80G8E9 - 27" IPS - UHD 4K - 144Hz 1ms - NVIDIA G-Sync - FreeSync - HDR 400 - USB Type-C
- Tablet felvásárlás!! Apple iPad, iPad Mini, iPad Air, iPad Pro
- AKCIÓ! HP EliteBook x360 830 G7 i5-10210U 16GB 512GB 1 év garancia
Állásajánlatok
Cég: NetGo.hu Kft.
Város: Gödöllő
Cég: Promenade Publishing House Kft.
Város: Budapest



![;]](http://cdn.rios.hu/dl/s/v1.gif)



