Hirdetés
- Lalikiraly: Mercis kalandok - Huszonnyolcadik rész - Az újrakezdés
- Lalikiraly: Kinek milyen setupja van?
- Graphics: Telefonvásárlási kálváriám....avagy clickbait cím: Horror a hardveraprón
- Luck Dragon: Asszociációs játék. :)
- Luck Dragon: Alza kuponok – aktuális kedvezmények, tippek és tapasztalatok (külön igényre)
- sziku69: Fűzzük össze a szavakat :)
- Parci: Milyen mosógépet vegyek?
- sziku69: Szólánc.
- bambano: Bambanő háza tája
- Elektromos rásegítésű kerékpárok
Új hozzászólás Aktív témák
-
Dinter
addikt
-
alapz@j
tag
válasz
dobragab
#5728
üzenetére
Már fentebb is linkelte valaki, de nekem több gondom is van ezzel a cikkel.
Egyrészt hibás nevezéktant használ, mert azt mondja, hogy van az UNICODE kódolás és az UTF8, holott az UTF8 az egy unicode kódolás.
Másrészt nincs olyan, hogy UNICODE kódolás - a cikk - pontos megnevezése nélkül - az UCS2-t mutatja be, illetve az UCS2-UTF8 konverziók egy részét.
Harmadrészt a cikkben szereplő függvények pont nem segítenek a kérdezőnek, mert neki az ASCII-UTF8 konverziókra van szüksége.
-
stepboy
csendes tag
válasz
dobragab
#5550
üzenetére
sziasztok,
Ezt a példát nem értem.
int temp = 1;
evil_api_function_call(fp, ptr, &temp);C99-ben tudod lokális változónak is képezni a "címét" egy trükkel. Pontosabban: tudsz compound literal segítségével temp tömböt létrehozni egy elemmel, ami viszont már konvertálódik pointerre.
Tehát azt akarod mondani, hogy lokális változó címét nem lehet paraméterként átadni függvényhíváskor?
-
EQMontoya
veterán
válasz
dobragab
#5679
üzenetére
Linus is csak a hírnevéből él, meg az odaszólogatós leveleiből, amúgy meg faszságot beszél régóta.
Konkrétan az egyik projekten újraírtunk pár C kódot C++-ban, és azon felül, hogy fele annyi kód lett, konkrétan gyorsabb lett, mert jobban tudta optimalizálni a fordító a több rendelkezésre álló információ miatt.
Szóval Torwalds a múltban él és a múltat nézi, így hát seggel megy a jövőbe.
-
maestro87
őstag
válasz
dobragab
#5672
üzenetére
Igen, közben rájöttem, hogy két egymásba ágyazott
if(vagy egyif-ben két feltétel) többet ehet memóriában is.Ha struktúrákat használok az nem nevezhető már objektumorientált programozásnak? Nekem egyszer valaki azt mondta a forráskódomra, hogy olyan mintha C++-ban lenne, pedig akkor még nem is nagyon használtam struktúrákat sem.
(#5673) ToMmY_hun: C++-t Visual Studio-ban szeretném majd használni, azért tanulgatom, nem MCU-hoz.
(#5674) EQMontoya: Sok lúd disznót győz.
Meggyőztetek. 
(#5675) ToMmY_hun: Már azzal is baj van?
-
maestro87
őstag
válasz
dobragab
#5657
üzenetére
Én ugyan C-ben még nem használtam
gotoutasítást, de sosem értettem, hogy miért félnek tőle az emberek.
Még talán assembly-ben is megkérdőjelezik a használatát, pedig ott tudtommal más megoldás nem nagyon van ciklusok létrehozására.Viszont a
continueutasítást valaki eltudná magyarázni, mert ebből nem nagyon értem. Ugyanaz lesz a kimenetcontinue-val és nélküle is, akkor meg minek bele?
-
maestro87
őstag
-
ToMmY_hun
senior tag
válasz
dobragab
#5657
üzenetére
Nekem az a tapasztalatom, hogy a spagetti kód nem a
gotomiatt lesz olyan, amilyen. A megfelelő szépérzékkel és odafigyeléssel bizonyos esetekben valóban szebb és átláthatóbb kódot lehet írni vele, de amiatt, mert nagyon nagy odafigyelést igényel, a használata nem célszerű. Viszont vannak olyan programnyelvek, amelyeknél agotomegkerülhetetlen. Ilyen például a VBA (Visual Basic for Applications), amelyben a hibakezeléshez biztosan, de ha jól emlékszem bizonyos esetekben acontinuehelyett is csakgotohasználható. Egyébként egy jól formázott és strukturált kódnál nem hiszem hogy nagy jelentősége lenne a kérdésnek. Nem szokás több száz soros függvényeket írni, sokkal célszerűbb kisebb darabokra vágni azokat, hiszen így sokkal átláthatóbb és nem utolsó sorban könnyen tesztelhető kód lesz az eredmény. -
#36268800
törölt tag
válasz
dobragab
#5605
üzenetére
Arra gondoltam, hogy egy láncolt listába beolvasom a sorok tartalmát, tehát a struktúrám valahogy úgy nézne ki, hogy
typedef struct lottoHet{
int szam1;
int szam2;
int szam3;
int szam4;
int szam5;
struct lottoHet *next;
}lottoHet;miután ez megvan, végigpörgetem a listát és megszámoltatom egy 90 elemű tömbben, hogy egy-egy számot hányszor húztak ki az eddigi évek során. Puszta kíváncsiságból szeretném megírni a programot. Nyilván minimális eltérés lesz egy-egy darabszám között, mivel "90 alatt az 5" a lottó 5ös valószínűsége.
Egyéni szórakozás...Alapvetően nem gondoltam arra, hogy megszámolnám a sorokat, inkább találja ki a program, legyen okosabb annál, mintsem hogy mindent "a szájába rágjak".
-
-
EQMontoya
veterán
válasz
dobragab
#5579
üzenetére
Nem a típustól függ, hanem az elhelyezkedéstől.
nyilván sizeof((void*)tomb) == sizeof(&tomb).Viszont két, azonos típusra mutató ptr nem feltétlen ugynaakkora. Persze x86-on nem lesz különbség, de amúgy, főleg embedded rendszerek esetén lehet. (mondjuk stack, heap és static között)
-
Jester01
veterán
válasz
dobragab
#5575
üzenetére
a címét nem képezhetjük, hiszen ahhoz először pointerré konvertálódik,
Szerinted. A szabvány szerint meg de. Idéztem ott feljebb kicsivel:
Except when it is the operand of the sizeof operator or the unary & operator
Tehát ha & operátort alkalmazol a tömbre akkor nem konvertálódik pointerré.
-
bepken
veterán
válasz
dobragab
#5563
üzenetére
akkor ezek szerint a string.h is használható! ezzel meg is oldódott a problémám, egy strlen segítségével könnyedén meglett az a fránya üres sor is
(másképp én nem tudtam megoldani)el is fogadta a kódot, úgyhogy köszi szépen
(hamarosan jövök újabb kérdésekkel )ez a feladat nem kifejezetten verseny feladat, csak egy beugró. szerencsére/sajnos itt még alap dolgok vannak. minden esetre én egyelőre vizsgán szeretnék átmenni, úgyhogy az egyszerűsítésnek csak örülni tudok
-
mepet
addikt
válasz
dobragab
#5507
üzenetére
C++-ul nem értek, de legalább ma is tanultunk valamit. Kézzel pötyögtem a kódot, és én nem literal méretét néztem, az életben eszembe nem jutott volna ilyen, hogy "visszafelé kompatibilitás miatt" ugyanaz a típus több byte-ot foglalhat csak azért, mert literal...
char a='a';
printf("%zu", sizeof(a));
printf("%zu", sizeof(+a));Ez pedig 14-et dob C-ben, és itt az a magyarázat, amit én mondtam, de persze mint kiderült a két kód között is van különbség...
[szerk] PellesC built-in complier LCC alapokon, -std:C11
-
maestro87
őstag
válasz
dobragab
#5477
üzenetére
Parancssorból szerintem senki se fordít PIC programozásnál. Én még nem láttam ilyet. MPLAB-ban rábökök a build gombra és lefordítja. Pragma utasításokban kell pl. megadni a PIC beállításait: órajel, kódvédelem, egyes lábak funkcióit...
De ettől függetlenül lehet nem pragma-val kell átállítani, de csak így fordult le. Lehetne beszédesebb is az az adatlap... Most guglival sem találtam semmit, de most mindegy is mert átálltam inkább egész számokra. -
maestro87
őstag
válasz
dobragab
#5469
üzenetére
Pedig azt hittem világos voltam. Ez XC8 fordító ami 8 bites PIC mikrokontrollerek egyik fordítója és eléggé különbözik a programozás órákon megszokott C-től a változó típusok terén. A pdf a 143. oldaltól kezdve ír a változótípusokról.
Ez a %d meg a %f biztos jól működik windows-on/linux-on, de PIC-nél sajnos vannak eltérések még a változók között is. Itt az int pl. csak 2 byte-os. A lebegőpontos típusokra vonatkozó adatokat meg sajnos még a mai napig nem tudom értelmezni, hogy meddig használhatóak.
Itt a float is csak 1-2 tizedesjegyig szokott pontos lenni, és nem értem miért.
Tehát, amit itt írtatok sajnos egyik sem működik jól.
Én csak ezzel az egyszerű sorral tesztelem egyelőre:
printf("%d", 6123456); // --> 28608-at ad vissza.
printf("%f", 6123456.0); // --> 6123520.000000
printf("%ul", 6123456); // --> 286081
Tehát amíg ezek sem működnek, nincs értelme szorzásról beszélni.
Ha nem muszáj meg nem szeretném két int típusú változóban tárolni a nem egész számokat is. -
mepet
addikt
válasz
dobragab
#5463
üzenetére
Igen, csak előre meghatározott számú sorig és előre meghatározott karakterszámig működik soronként.
A MAX_CHARS egy szerencsétlenül elnevezett, a progi elején általam definiált konstans. Sose használtam még CHAR_MAX-ot a limits.h-ból, de ahogy nézem, az csak a char típus által felvehető maximum érték, esetünkben a line[] tömb elemszáma akár lehet több is, mint a CHAR_MAX.
sprintf(lines[i], "%s", line); == strcpy(lines[i], line);
És tényleg.
Már csak az a kérdés, hogy miért hibával lép ki, ha ki X-elem, tippre valamilyen terület lefoglalva marad.
on me. 
Jogos.
Még talán assembly-ben is megkérdőjelezik a használatát, pedig ott tudtommal más megoldás nem nagyon van ciklusok létrehozására.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Köszi a segítséget. 
Itt a float is csak 1-2 tizedesjegyig szokott pontos lenni, és nem értem miért.Ú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!
- ASUS Rog Ally Z1 Extreme, 2027.01.12-ig gyári garanciás, hálózati töltőjével, szilikon tokkal eladó!
- HP 250 G7,15.6",i5-1035G1,8GB DDR4,256GB SSD,WIN11
- Lenovo ThinkPad T480s,FHD,14",i5-7300U,8GB DDR4,256GB SSD,WIN11,TOUCH,jó akku
- Lenovo ThinkPad T480s,FHD,14,i5-7300U,8GB DDR4,256GB SSD,WIN11,TOUCH
- Ugreen Revodok Max Thunderbolt 4, dokkoló, port többszöröző állomás
- Lenovo Thinkpad X1 Yoga 6th Gen. i7 11th, 32GB RAM 27% ÁFÁS (0326)
- Apple iPhone 14 Plus 128GB sárga használt, karcmentes 97% akku 6 hónap garancia
- Sony PS3/PS4/PS5 és kézikonzolok Okosítása és Szoftveres szintű javítása - MÁR 13.00-S PS4 IS!
- iKing.hu Realme 14 Pro+ Pearl White 512GB használt karcmentes 6 hónap garancia
- iPhone 17 256GB - BONTATLAN - (3év)
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest