- Google Pixel topik
- Samsung Galaxy A55 - új év, régi stratégia
- iPhone topik
- Apple iPhone 16 Pro - rutinvizsga
- Realme GT Master Edition - mestermunka
- Karaktere biztos lesz az első Nothing fejhallgatónak
- Apple Watch
- Hivatalos a OnePlus 13 startdátuma
- Íme az új Android Auto!
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
Ú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 velemhogy 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
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!
- Szép Dell Latitude 7320 -60% "Kis Gamer" Üzleti Profi Ultrabook 13,3" i7-1185G7 32/512 FHD IRIS Xe
- LG NanoCell 50NANO759PR
- Samsung Galaxy S23 256GB (garis)
- i7 8700/ 32GB DDR4/ 512GB gen4 SSD/ R5 430 2GBD5/ HP 400G5 SFF/ garancia/ ingyen foxpost
- HUAWEI WATCH GT5 46 mm Active, két hetes készülék, kb 23 hó garancia, ÜZLETBŐL
- BESZÁMÍTÁS! GIGABYTE AORUS MASTER RTX 3070 8GB GDDR6 videokártya garanciával hibátlan működéssel
- Eladó Új Motorola G31 4/64GB szürke / 12 hónap jótállással!
- AZONNALI SZÁLLÍTÁS Eredeti Microsoft Office 2019 Professional Plus
- ÁRGARANCIA!Épített KomPhone i5 10600KF 16/32/64GB RAM RX 6600 8GB GAMER PC termékbeszámítással
- Honor Pad X8a 64GB Wifi,1 év Garancia
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest