Hirdetés
- Poco F8 Ultra – forrónaci
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Kicsomagoljuk és bemutatjuk a Poco F8 Ultrát
- Youtube Android alkalmazás alternatívák reklámszűréssel / videók letöltése
- Xiaomi 14 Ultra - Leica hercegnő
- Milyen okostelefont vegyek?
- Jelentősen átalakulhat a Xiaomi 17 Ultra kamerarendszere
- Vivo X300 Pro – messzebbre lát, mint ameddig bírja
- Google Pixel topik
- Okosóra és okoskiegészítő topik
Ú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!
- GAMER Asus ROG NVIDIA 6gb dedikált / i7-10750h / 16gb ram / 500gb ssd / MAGYAR rgb bill / win11
- Prémium Lian Li O11 Gamer/Workstation PC - Ryzen 9 5950X, RTX 4070 Super, brutális teljesítmény
- Lenovo ThinkPAD 15 GEN2 / Intel core i5-11generáció / 16gb DDR4 ram / 512gb NvMe SSD / WIN11
- LOQ 15IRX9 15.6" FHD IPS i7-13650HX RTX 4050 16GB 512GB NVMe magyar vbill gar
- Újszerű Apple Macbook Air 13 - M2 - 8/256GB (MLY33MG/A) éjfekete - 24 Ciklus - 100% akkumulátor- HUN
- Bomba ár! Dell Latitude 5491 - i7-8850H I 16GB I 512GB SSD I 14" FHD I HDMI I Cam I W10 I Gari!
- iKing.Hu-Samsung Galaxy S25 Ultra Titanium Black 12/256 GB-karcmentes Garancia 2028. 08. 23-ig
- GeForce RTX 2070 blower (OEM HP) Garanciával
- Telefon felvásárlás!! iPhone 12 Mini/iPhone 12/iPhone 12 Pro/iPhone 12 Pro Max
- Wacom Bamboo One CTF-430 rajztábla
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: BroadBit Hungary Kft.
Város: Budakeszi



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




