Ú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
goto
utasí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
continue
utasí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
goto
miatt 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 agoto
megkerülhetetlen. Ilyen például a VBA (Visual Basic for Applications), amelyben a hibakezeléshez biztosan, de ha jól emlékszem bizonyos esetekben acontinue
helyett is csakgoto
haszná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
-
dabadab
titán
-
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.
Ú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!
- Dell XPS 3K Érintős,core i7,16GB RAM,256-512GB SSD,ÚJ AKKU,ÚJ TÖLTŐ,Szép állapot
- AKCIÓ!!!Acer V3,FullHD core i5 6200u(4X2,8Ghz),8GBRAM,nVme
- Újszerű Lenovo,15,6"FullHd IPS,Ryzen 5(8x3,7Ghz)VEGA 8 VGA,12-20GB RAM,SSD+HDD
- Lenovo 14,1"Áthajtható Érintős FullHd,Ryzen 3,VEGA VGA,8-16GB DDR4 RAM,256-512SSD,Szép állapot
- ASUS GeForce GTX 1650 Phoenix OC 4GB GDDR6
- Realme C30 32GB, Kártyafüggetlen 1Év Garanciával
- Azonnali készpénzes GAMER / üzleti notebook felvásárlás személyesen / csomagküldéssel korrekt áron
- ÁRGARANCIA!Épített KomPhone Ryzen 9 5900X 16/32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- ÁRGARANCIA! Épített KomPhone i5 12400F 16/32/64GB RAM RTX 5060 8GB GAMER PC termékbeszámítással
- ALIENWARE Area-51 R6 Threadripper Edition 1920X
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest