Új hozzászólás Aktív témák
-
buherton
őstag
válasz
kovisoft
#6373
üzenetére
Úgy érzem, hogy ezt nem fogom megérteni soha. Évek óta nem nyúltam C kódhoz csak C++-hoz, de annak is már 2 éve. Bár ezekkel akkor sem voltam tisztában.
Ráadásul rettenetesen bosszant az, hogy több C kvízes oldalon vannak hibás feladványok. Az egyik típus hiba az volt, hogy a függvény int-t várt és rendbe ott volt az if, hogy csak 0-nál nagyobb számokkal foglalkozzon. Negálás sehol nem volt, vagyis negatív számokra nem működik jól a függvény. A másik típus hiba az, hogy a két sequence point között csak egyszer lehet az értéket módosítani. Illetve volt még olyan is, hogy singed negatív számot akart shiftelni, ami undefined.
struct player
{
char pname[20];
}pl;
char* play(struct player *temp_pl)
{
strcpy(temp_pl->pname, "kohli");
return temp_pl->pname;
}
int main()
{
strcpy(pl.pname, "dhoni");
printf("%s %s", pl.pname, play(&pl));
return 0;
}Ez is egy kvíz, ahol nincs olyan opció, hogy undefined. Undefined-nak gondolom, mert a függvény paraméter kiértékelés sorrendje nincs leírva a szabványban.
-
-
buherton
őstag
Lenne egy számomra fogós kérdés.
Az alábbi kódrészletben miért biztos mindenki, hogy a pointer majd az inkrementált címre fog mutatni az értékadáskor az alábbi kódrészletben?
*p++ = 1;Keresem az okot a miértre, de őszintén nem találom. Annyit sikerült kideríteni, hogy nem a precedencia az ok.
A C99 szabványban (alább a részletek) úgy értelmezem, hogy ténylegesen bármikor megtörténhet két sequence point között.
Ráadásul ez a leírás is csak ráerősít arra, hogy az order unspecified: [cpp reference - Order of evaluation]
Segítene valaki felhomályosítani ebben az ügyben?
-
buherton
őstag
válasz
jattila48
#6331
üzenetére
A másik függvény a struktúrát nem inicializálta, hanem csak olvasta. Így történhetett meg ez a csodás hiba. Ez gyakorlatilag egy értékadás volt
.A többire. Amit nem javítottam ott tényleg sok mindent kellett volna átírni. Erre már nem volt idő. Egyébként igazad van elméletben. Én még ezzel a mentalitásommal - mármint hogy a feladathoz nem kapcsolódó hibákat javítsak - még ki is lógok a többiek közül. Ebbe és több más dologba is beleállok.
Nem tudok többet hozzáfűzni, mint amit dabadab írt.
-
buherton
őstag
válasz
kovisoft
#6329
üzenetére
Hirtelen nem fogtam fel a kódot és azt hittem ez két külön megoldás. Igen, egyébként pont így van. Annyit tennék hozzá, óvatosan azzal, hogy “nem fog hivatkozni rá senki”
![;]](//cdn.rios.hu/dl/s/v1.gif)
.Nem is olyan régen találtam egy elég nagy program részt ahol tömegével voltak ilyen már nem érvényes memóriára való hivatkozások. Megpróbáltam kijavítani, de csak több ilyen hibába futottam. Inkább gyorsan dobtam a módosításom és fütyürészve tovább álltam, mintha mi sem történt volna. Soha nem csináltam még ilyet, de az a katyvasz hetekre magával rántott volna. Köszöni szépen azóta is “jól” van.
Egy másik sztori. Kernel spaceben ügyködtek a “kompetens” kollegák. Egy függvény lokálban létrehozott egy struct-t, ami aztán meg is szűnt. Aztán jött egy másik függvény, ami szintén létrehozta a saját structját. Aztán jöttem én. Teljesen más helyen javítottam egy bugot, amire elkezdett a kernel pánikolni. Kiderült hogy a másik függvény structja a előző struct értékeit olvasta ki a stackről és a módosításom csúsztatott annyit a stacken, hogy pont ne passzoljanak.
-
buherton
őstag
válasz
pmonitor
#6291
üzenetére
*leírom ismét, amit eddig leírtam a goto-ról és annak használhatóságáról*
Azért legyünk őszinték: sem a tömeges goto, sem az egymásba ágyazott if nem szép.
Ki mondta, hogy tömegesen kell a goto-t használni?
Azok a nevek C-ben dolgoztak? Nem emlékszem már kikről van szó, csak annyi maradt meg hogy BASIC, meg Pascal?!
Továbbra sem értem, hogy miért kell az almát a körtével összehasonlítani.
-
buherton
őstag
válasz
pmonitor
#6285
üzenetére
Rendben, vegyük végig.
Hiába mutattuk meg, hogy a goto hatékony, továbbá egyszerűbben és hatékonyabban le lehet írni valamit gotoval, mint a nélkül. Nem fogadtad el és ütötted tovább a vasat.
Hiába lettek komoly nevek megemlítve a Linux területéről, akik mérvadónak számítanak a szakmában. Nem fogadtad el és ütötted tovább a vasat.
Most olyan nyelvekkel jössz, aminek minimális, de inkább semmi köze sincs a C-hez vagy annak a filozófiájához, de mégis jön a méricskélés és az összehasonlítás, meg a bezzegek.
Leírom még egyszer: Az objektumorientált nyelvekben azért nem kell a goto, mert ott a class destructor-ral meg constructor-ral ezeket szépen le lehet írni. Vagy ha azokkal nem is, akkor még mindig lehet exception-t dobni. Sőt, kiegészítem a funkcionális programozással, ami már non plusz ultra.
Ha most ebben is megfogunk, akkor mi lesz a következő?
-
buherton
őstag
válasz
pmonitor
#6282
üzenetére
Almát a körtével? Most komolyan? Jó, menjünk bele. Az objektumorientált nyelvekben azért nem kell a goto, mert ott a class destructor-ral meg constructor-ral ezeket szépen le lehet írni. Vagy ha azokkal nem is, akkor még mindig lehet exception-t dobni. A C-ben nincs ilyenek, így marad a goto.
Nem értem a motivációdat btw.
-
buherton
őstag
válasz
pmonitor
#6269
üzenetére
Ühüm, szóval azt mondod, hogy Jonathan Corbet, Alessandro Rubini, és Greg Kroah-Hartman buták, akik nem tudják hogyan kell programozni?
Továbbá leírtam azokat az eseteket is, amikben a példád elbukik. Mindezek ellenére csak azért is kötöd az ebet a karóhoz, hogy a goto rossz.A laposföld-hívőkkel nem tudok mit kezdeni így feladom. Ezzel együtt felveszem az interjú kérdéseim közé a goto kérdéskört, mert többet ér az idegrendszerem ennél.
Igen, kirekesztő vagyok, mert kirekesztem a másként gondolkodókat
.#6275 pmonitor: Most már ha felverted a port magad körül, ne fuss el.
-
buherton
őstag
válasz
#90088192
#6266
üzenetére
Vagy nem teljesen érthető a kérdésed, vagy nekem vagy nagyon hétfő.
Ha jól azt szeretnéd elérni, hogy ne kiszámolja, hanem rögtön adja vissza az értéket, ugye? Gondolom ez a sebesség miatt kell.
A lookup table-re keress rá. Ezt sokféleképpen lehet implementálni. Talán a legegyszerűbb, hogy minden fokra legenerálod előre egy tömbbe és majd arra hivatkozol. Valahogy így:
const float degree_to_sin[] ={0, /* 0 degree */0.017, /* 1 degree */...};float res = degree_to_sin[1]; // res = sin(1)Persze ilyenkor a pontossággal lehetnek gondok.
-
buherton
őstag
válasz
pmonitor
#6260
üzenetére
Nem használok 2-nél mélyebben if-eket, mert annál több pont az ellenkezőjét éri el.
A verziód azért nem jó, mert:
- ha a 'this' megváltozik, akkor a unreg-es párját több helyen is át kell írni
- ha új resource jelenik meg, mint modjuk a 'these', akkor lehet copy-pastelni és +1 mélységet kap ez a csoda if szerkezet
- antipattern és jobb helyeken az ilyeneket be sem lehet szállítani, mert a checkerek megfogják -
buherton
őstag
válasz
pmonitor
#6235
üzenetére
[centralized-exiting-of-functions]
vagy
int __init my_init_function(void) {int err;/* registration takes a pointer and a name */ err = register_this(ptr1, "skull");if (err) goto fail_this;err = register_that(ptr2, "skull");if (err) goto fail_that;err = register_those(ptr3, "skull"); if (err) goto fail_those;return 0; /* success */fail_those: unregister_that(ptr2, "skull");fail_that: unregister_this(ptr1, "skull");fail_this: return err; /* propagate the error */}amikor nem tudtad másképp megoldani?
Jaj, az annyira olyan ez a kérdés. Lehet programozni if-else nélkül is. Lehet programozni for, while, do-while nélkül is, de nyilvánvalóan nem érdemes. -
buherton
őstag
válasz
pmonitor
#6231
üzenetére
Az egyetemi elmélet és a gyakorlat jellemzően nincs párban.
Ott az OpenFlow, amiről 1001 publikáció készült, de a gyakorlatban kb senki nem használja.
A legtöbb network protokoll is fantasztikus elméleti háttérrel rendelkezik, de a gyakorlati alkalmazásban már megy a tákolás, mert pl. a biztonságra nem gondoltak az akadémikusok. Erre kiváló példa az IPv6, vagy nagyjából az összes network protokoll.
Úgy érzem, hogy itt is egy hasonló vita alakult ki. Van egy ékesnek tűnő elképzelés, ami egyetemi keretek között maradéktalanul megállja a helyét, de a gyakorlatban már nem mindig tartható mindenféle olyan okból, ami az egyetemen nem is létezik.
Csak néhányszor írtam le goto-t az elmúlt 7 év alatt, de annak jó oka volt. Egyébként én sem pártolom a használatát, de néha nagyon jól jön.
-
buherton
őstag
-
buherton
őstag
Aki tanított neked az egyetemen kívül nem dolgozott. A papír/publikáció sok mindent elbír.
Ha bármelyik nyelvi elemet nem úgy használod ahogy kell, akkor is olvashatatlan és debuggolhatatlan lehet a kód.
Nem hiszem, esetleg WSL-ben mehet, azt próbáltad már?
Windows-on fejleszteni
. -
buherton
őstag
Bár C++, de nagyon jó: [Google C++ style guide]
Coding rules: [SEI CERT C]
Hogy ellenőrizni is tudd a kódot: [CodeChecker]
A globális változókat és a gotot kategorikusan elutasítani elég buta dolog. Hatékony eszközök bizonyos problémák megoldásához.
-
buherton
őstag
Úgy kell neki állni, mint egy normál programozási feladat. Nézzük meg mit csinált más
.Mielőtt beleugranál a programozásba érdemes kézzel kipróbálni azt, amit végül csinálni akarsz. Ehhez először olvass el néhány releváns how-to-t. Ezzel ki fogod ismerni magad a kulcsok világában és hogy az openssl-el ez hogyan működik. És megismered a hibaüzneteket, no meg azok formátumát
.Ha ez megvan akkor érdemes megnézni a példa programokat. Például: Darrenjs [link]
A githubon találtam még régebben valahol egy nagyon jó example-t, amiben több formátumú kulcsra is voltak különféle példák.
Az openssl-nek van a neten dokumentációja, de szerintem rossz az elnevezés, mert az inkább egy referencia.
-
#6071
buherton
őstag
Ereshkigal
#6068
buherton
őstag
válasz
Ereshkigal
#6068
üzenetére
Igaz is meg nem is, mint a mesében. Fájlra lokális vagy globális lesz a függvény a static kulcsszóval. Szerintem jattila48 a lambda és társai gondolt, ami mint nyelvi elem hiányzik a C-ből. Ettől persze implementálható, ahogy az egéz C++-t. Most hirtelen nem találom ezt a könyvet, de arra emlékszem, hogy temérdek void* és -> volt benne
. -
#6058
buherton
őstag
borisz1994
#6057
buherton
őstag
válasz
borisz1994
#6057
üzenetére
Nem egészen. Vagyis hát nem olyan triviális. Főleg a változóknál.
A deklaráció a fordítónak szól, vagyis ez ahhoz kell, hogy a fordító értelmezni tudja a leírtakat, de nincs közvetlen hatása a processzoron futó kódra. Azaz meg lehet írni a programot ezek nélkül, csak olvashatatlan lesz. A definíció a processzornak szól és enélkül nem futna úgy a programunk, ahogy szeretnék.
Kezdjük az egyszerűbbel a függvénnyel.
Ezek deklarációk:
extern void foo(void);static int foo(int);void foo(void);bar(); // ez most nem függvényhívás, és ez most nagyon gonosz dolog tőlem
A fordítónak ezekkel jelzed, hogy ha talál egy ilyen szignatúrájú függvényhívást, amihez még nem találta meg a definíciót, akkor ne hasaljon el és a keywordnek megfelelően járjon el.Ezek definíciók:
void foo(void){}static int foo(int){return 0;}bar(){return 0;}
Leírod, hogy mit csinál a függvény. Ezzel mondod meg, hogy mit csináljon a programod.Változók.
Ez deklaráció (nem is tudok többet ennél):
extern int;
Ugyanaz, mint a függvénynél.Ezek definíciók:
int foo;static char foo;
Ugyanaz, mint a függvénynél.Egyébként igen, a deklaráció nem jár memóriafoglalással, a definíció jár. Viszont a deklaráció csak a láthatóságot növeli, semmi más plusz dolgot nem tud, nem befolyásolja a típust, élettartamot és a tárolási osztályt sem.
Az
intmérete architektúra függő és alimits.h-ban van meg a "mérete". Tipikusan 4 bájt. Ha jól emlékszem, akkor az AVR8 esetén 2 bájt méretűek. -
buherton
őstag
válasz
#90088192
#6051
üzenetére
Minden .c fájlból fordítódik egy .o fájl. A .o fájlokat fogja a linker összeszerkeszteni, aminek a vége egy bináris, amit te is használni fogsz. A .h fájlok, azért kellenek, mert abban vannak deklarálva a .c/.o szempontjából a külső függőségek, amiket a linker old fel a bináris összeállítása során.
Példa: A foo.c-hez kell tartoznia egy foo.h-nak, amiben a foo.c kívülről is elérhető makrók, típusok, változók és függvények vannak felsorolva. A main.c-ben elég a foo.h-t includolni, hogy a main.c leforduljon. Majd a linker összerakja a két .o fájlt.
A fordítást/linkelést az IDE tipikusan megoldja, neked csak a forrás fájlokkal kell bíbelődni.
-
buherton
őstag
válasz
#90088192
#6049
üzenetére
screen.h
void delay(unsigned int usec);
void lcd_select(int s);
void strobe_E(void);
void set_y(int y);
void dsp_on(void);
void clr_scr (int t);
void write_char(int line_select, int y_offset, int c);
void string_out(char* message, float variable, char line, char y_offset);A
hardware.h-ban pedig függvény definíciók vannak a deklarációk helyett. Nem illik ilyet csinálni. De ha nagyon muszáj, akkor azinlinekulcsszót kell elétenni.Kerüld a fölösleges pontosvesszőket. Nem illik ilyet csinálni.
Ha pedig
voida függvény paramétere, akkor írd ki, mert így variadikus lesz.A register map-re struktúrát és uniont szoktak ráhúzni és akkor nagyon frankón végigkövetehető, hogy ez melyik regiszter. A macro mágiát érdemes elkerülni.
Az include pathért legyen a build környezet felelős és ne hardcode-ld bele a kódba.
-
#5936
buherton
őstag
f(x)=exp(x)
#5935
buherton
őstag
válasz
f(x)=exp(x)
#5935
üzenetére
Másold be ide.
-
#5917
buherton
őstag
Krisztiiii
#5916
buherton
őstag
válasz
Krisztiiii
#5916
üzenetére
A C-nek nincs GUI-ja.
-
buherton
őstag
De lehet, ha Cygwin-t raksz alá. Egyszer csináltam ilyet Eclipse-szel, de halál volt
.A CodeBlocks egy IDE, amivel a kódot tudod szerkeszteni, fordítani, futtatni és debuggolni. Csak ugye mindez a windowson történik. A regex pedig POSIX.2 szabvány van definiálva. Ehhez Unix-szerű környezetnek kell, hogy fusson a gépeden.
A C-t nem a windows-ra találták ki.
-
buherton
őstag
Ez így biztosan nem jó:
printf("%d/%d",sorok8/jo8);, ezt próbáld helyette:printf("%d/%d",sorok8, jo8);. Ascanfhelyett használd azfgetsfüggvényt. Osztást érdemes elkerülni ha lehet, mert erőforrás igényes.A legfontosabb soha ne adj ki úgy kezedből progamot, hogy előtte nem próbáltad. 99,99999% az esély arra, hogy rossz
.Tegyél fel Cygwint gcc-vel, vagy virtuális gépre rakj fel egy Linuxot.
-
-
buherton
őstag
Nekem eddig egyszer sikerült két csillagos pointert leírnom a saját kódban, mert azzal volt a leghatékonyabb. Különben mindig kerülöm a használatát, mert az ember gyorsan bele tud zavarodni. Ezt javaslom neked is. A Linux függvényei közül is eddig csak eggyel találkoztam, amit két csillagot várt: scandir
u8b data[] -> ez nagyon csúnya.
Mitől csúnya? Inkább u8b* data legyen? Még előnybe részesítem a tömböket a pointerekkel szemben, mivel azokat könnyebben kezelem. 8bites uC-n is könnyebben nyomon tudom követni, hogy mennyi RAM-ot is használok...u8b data[] -> ezzel fölöslegesen foglalsz 512 bájtot a stacken, ami ugye még processzor idő is. Használj pointert. (Egy ilyen miatt én simán buktatnék egyetemen.)
A fordítótól függ, hogy hogyan align-olja a structúra változóit. Bár ez 8 bites, így nem valószínű, hogy máshogy align-olna, de a hordozhatóságot javítja.
, majd ha másolom/küldöm az adatcsomagot akkor a b[]-t használom.
Másolás ->memcpy, küldés bájtonként pedig char*-al tudsz küldeni. Ergo nem kell a union. Nem is értettem az elején, hogy miért is kellett.
dns_answer*& dns_response
Szerintem így sokkal olvashatóbb és nem utolsó sorban sokkal helytakarékosabb és gyorsabb.
void get_data_from_dns_reply(u8b* data, dns_header* dns_resp_header, dns_answer*& dns_response)
{
memcpy(dns_resp_header, data, 12);
dns_response = (dns_answer*)malloc(htons(dns_resp_header->answer_rrs.i) * sizeof(dns_answer));
for(; data[i] != 0; i++)
{
i += data[i];
}
i += 5;
for(u16b j = 0; j < htons(dns_resp_header->answer_rrs.i); j++)
{
i += 12;
memcpy(dns_response[j].data, &data[i], 4);
i++;
}
}MOD: ezen a kódon még bőven lehetne optimalizálni, csak nem látom a többi részt.
MOD2: jah és igen. Malloc + 8 bites MCU? Remélem fut valamilyen OS ezen program alatt, ami a fizikai memóriát rendezi, mert az ilyen malloc-olás magában hordozza azt, hogy a kész programod egyszer beáll, mint a szög. A beágyazott rendszerben alapvetően tiltott a malloc használata.
-
buherton
őstag
dns_answer local_answer -> ez nincs használva.
dns_response -> nincs deklarálva.
local_dns_resp -> nincs deklarálva.
A struct-hoz erősen javaslok egy packed attribute-omot.
dns_answer** answer -> ezt nem használod semmire.
u8b data[] -> ez nagyon csúnya.
Minek union?
A for ciklikusok, miért is nem memcpy-k? Ez nem C++ ahol számít, hogy a konstruktor adott esetben meghívódjon.A hiba itt van:
*dns_response[i] -> *(dns_response[i]);szerintem így helyes, de lehet, hogy nekem van nagyon péntek este. -
-
buherton
őstag
-
#5702
buherton
őstag
Neil Watts
#5701
buherton
őstag
válasz
Neil Watts
#5701
üzenetére
Szia!
Jó gondolat a karaktertömb és jó a probléma felvetés! Fél siker.
Egy struktúrát használnék pl.:
typedef struct
{
char isMinus;
unsigned int len;
char *number;
} number_sA fájlban ASCII-ként van letárolva, így amikor letárolnám a struktúrámba, akkor kivonnám az offsetet és egyszerű számként tárolnám, hogy később a műveletek során már ne kelljen ezzel foglalkozni.
A műveletek kicsit összetettebbek, de valóban a papíron való számolásra érdemes visszavezetni. Amiből kindulhatsz, hogy összeadásnál a leghosszabb szám hossza vagy plusz egy lesz az összeg hossza. Kivonásnál maximum a leghosszabb szám hossza.
Amit viszont ne kövess el, hogy konstans értékeket használsz! Ha ismerkedsz még csak a nyelvvel, akkor a prototípus lehet fix számú és akkor a logikát ki lehet próbálni, de utána illik generálissá tenni. Ehhez pedig melegen ajánlom a malloc/free függvényt. A struktúrában sem véletlenül van tömb pointer
. -
buherton
őstag
-
buherton
őstag
-
-
buherton
őstag
válasz
maestro87
#5447
üzenetére
Írásra törlődő regiszterek esetén határozottan célszerű a maszkolás, vagy ha nem direktben egy címre írsz, hanem mondjuk egy struktúra pointer által mutatt pointerre, ahol már nincs castolás, és kapásból memória korrupció léphet fel. Ez kvázi egy ököl szabály, hogy csak azokat a biteket engedjük át, ami valós értéket képviselnek. A többi maszkoljuk.
Közben eszembe jutott még egy példa. Mi van ha a változó értéke éppenséggel -1? Az egész változó tele van 1-esekkel.
MOD: ilyenekre nincs iromány.
-
buherton
őstag
-
buherton
őstag
válasz
dabadab
#5259
üzenetére
Pont a napokban turkálok egy olyan kódban, amiben goto van. Én még életemben nem írtam még goto-t kódba, de ezt annyira jól eltalálták és annyira leegyszerűsítette a program megértését és futását, hogy az már zseniális. Nem az ördögtől való, de csak akkor használja az ember, amikor tényleg ezzel egyszerűbb, mert nagyon átláthatatlan lesz. Főleg ha modulok között ugrál, nem csak függvényen belül.
MOD: off
-
buherton
őstag
válasz
alapz@j
#5235
üzenetére
Helyes. Azt hittem, hogy már senki nem foglalkozik ezzel
. Ennek a megoldásnak az a lényege, hogy olyan függvényt használjunk, aminek van valamilyen visszatérési értéke (printf-el is lehetett volna), és hogy egy ciklus vagy elágazás kiértekélésekor hi'vjuk meg ezt a bizonyos függvényt.Másik? [link] (cask vessző helyett pontos vesszővel, és lefordi'tani nem illik)
-
buherton
őstag
válasz
EQMontoya
#5214
üzenetére
Nem, nem fér el, lásd: [link].
(#5216) EQMontoya: Tényleg pontos vessző kellett volna. Elég régen kellett már bitfield-el mókolni, így nem voltam biztos, hogy vessző vagy pontos vessző kell. Ebben igazat adok, viszont a feladat továbbra is adott. Mennyi a mérete a bitfield-nek?
-
buherton
őstag
-
buherton
őstag
válasz
CPT.Pirk
#5100
üzenetére
Hóhó ez nagyon spéci cucc. Akkumulátor töltő vagy mi lesz belőle?
Most nekem is lenne egy kérdés. Nem igazán C viszont ha már felmerült az ARM, akkor megkérdezem.
Context switcher-t írok, de van két probléma, amivel nem tudok dűlőre jutni:
1. PendSV-ben történik a váltás, ahol értelemszerűen az MSP-t használom. Igen ám, de a stack pointer minden egyes meghíváskor 0x20-val csökken az értéke. Miért csinálja ezt?2. Így térek vissza a PendSV-ből:
volatile uint32_t LR_reg;
LR_reg = 0xFFFFFFFD;
__asm volatile ("BX %0" : "=r" (LR_reg));
Ennek ellnére még mindig privileged módban fut a cucc. Ha ez előtt beállítom direktbe a CONTROL regisztert, akkor user-ben fog futni, de nem erre találták ki az EXEC_RETURN-t? -
buherton
őstag
válasz
CPT.Pirk
#5095
üzenetére
Jól megkavarod a dolgot.
Nem ismerem a CooCox-ot (LPCexpresso-t használok), de projekt mappában van a lib és h? Abszolút vagy relatív path? Utóbbinál jó a változó? Jogok jól vannak beállítva (Linuxon). Ezek voltak a basic kérdések.
Advanced level: gondolom itt van is console felület, ahol kiírja, hogy a linker-t milyen arugmentumokkal hívja meg. Itt megnézd meg, hogy a lib és h (nem tudom melyiknek kellene ott lennie) benne van-e. Ha benne van, akkor passz, ha nincs akkor itt a gond. Továbbá próbálkoznék azzal is, hogy kimásolnám az egész sort és kézileg próbálnám összelinkelni. Ha eddig semmi sem volt jó, akkor indulhat a szarakodás.
Munka (nem ócó a Keil)? Milyen NXP? Mit csinálsz ezzel? Miért nem arm-none-eabi? Bár ha fontos a kód méret, akkor megértem.
-
-
buherton
őstag
1.
Ezt ne is próbáld megfejteni, mert unspecified az inkrement és dekrement kiértékelési sorrendje ilyen esetekben.2.
Nem szükséges az L, mert a fordító castolni fogja, de ajánlott, mert így szép.3.
Ilyenekkel ki lehet kergetni a világból . Az elmúlt 4 évben egészen biztosan nem írtam le még gondolatban sem a scanf-t 
.4.
Nincs különbség. Az utóbbit ajánlatos használni, mert nem típus, hanem a változó lehet pointer.5.
Lehet, mert az enum egy számot reprezentál, viszont nem ajánlatos íly módon használni, mert nagyon megtudja keverni az embert.+1.
Erre van egy uppercase vagy milyen standard függvény. -
buherton
őstag
válasz
moseras
#4878
üzenetére
Ez sajnos nem játszik, mert az uint8_t valójában 16 bitet "foglal" ki, amit csak #pragma-val vagy attribute-al lehet alignolni 8 bitre. Ezt viszont nem szarkazmusból mondom, mert a jó múltkorában ez okozott komoly fejfájást a 32 bites PowerPC-n.MOD: Tömb... Áh, a fene este van, és azt hiszem inkább csöndben maradok.
-
buherton
őstag
válasz
moseras
#4875
üzenetére
Felhívnám a figyelmedet erre:
. Szarkasztikus kötekedést próbáltam jelezni ezzel, de úgy látom sikertelenül. No de, hogy tényleg kötekedjek, legközelebb $ helyett > használj, mert az előbbi az általánosab elfogadott user prompt jele Unix rendszereken. (hát ha most már érthetőbb ) -
buherton
őstag
válasz
don_peter
#4863
üzenetére
Az RS232 aszinkron, az SPI szinkron ráadásul az előbbinél működik az egy irányú kommunikáció az utóbbinál kétirányú forgalom kötelező. Amire te gondolsz azaz UART, USART vagy USI. Lábnevek: Rx és Tx. Mint már fentebb írtam, hogy a stream redefiniálással lehet ügyködni, ha támogatja a fordító, és pont alkalmazható, mert a C ASCII alapú, ami 1 byte széles, és a soros porttól kezdve, minden periféria byte alapú.
-
buherton
őstag
válasz
don_peter
#4849
üzenetére
Mennyi RAM és flashed van? A static tömböket rakhatod a flashre is ha nincs elé RAM-od (compiler manualt kell megnézni). A számokat pl. a tömb méret for ciklus meddig menjen, azokat ajánlott #define-olni. Ez sem rossz forma mask = 0x10;, de ez olvashatóbb mask = (1<<4) és nem foglal több helyet, mert a fordító az ilyeneket kiszámolja. mask >>= 1; ez is inkább így mask = (1<<(z + 4));, mert ebből a sorból már látod, hogy a 4. bittől fölfelé akarod a biteket elérni és nem kell még feltekeni, hogy mi is volt a kiinduló érték. De ez minden rajtad, csak az olvashatóságon szeretnék segíteni.
-
buherton
őstag
Enum
A 8 bites architektúrán az enum 8 biten van ábrázolva, ami nem okoz gondot, ha memset-elni szeretnénk a tömböt hiszen az is bájtszintű. Viszont 32 bites architektúrán az enum 32 biten van ábrázolva, ami ugye 4 bájt. Ekkor ha deklarálsz egy tömböt, akkor egy tömb elem 4 bájt, viszont a memset továbbra is 1 bájtot állít. Így a 0 kivételével nem azt fogja csinálni, mint vártuk.
Komment
// komment \
komment \
komment \
komment vege Ugy hogy ovatosan a \-el, mert meg tud szivatni.(#4825) k.kristof: nekem beágyazott rendszerek a területem, itt egy kicsit más várnak el.
MOD: eszembe jutott még egy
Az előbbi leforul, ez viszont nem fog:
// komment \
komment \
komment \
komment vegePróbáljátok csak ki
. -
buherton
őstag
Munkáltató teszteken nem ilyen jellegű kérdések szoktak lenni, hanem írjon algoritmust és a fentebb írt szivatós kérdések.
(#4822) axioma: Ha jelentkezőt kellene tesztelni ahhoz lenne pár ötletem és akkor saját kútfőből, saját tapasztalatom alapján állítanám össze. A probléma, hogy most más állítja össze és én a másik oldalon ülök.
Például az enum-os kérdésem tapasztalatból jön. Adott volt egy enum tömb, amit használtunk 8- és 32 bites architektúrán is. A probléma ott kezdődöt, amikor memset-el 0-tól különböző értékkel próbáltuk inicializálni a tömböt.
MOD: eszembe jutott még egy. Ugye ezzel // egy sort lehet kikommentezni, vagy mégsem?
-
buherton
őstag
Oké
.a[i] = i++;
Mit eredményez?
char foo[3] = "bar";
Mi lesz a tömbben?
char *string = "foo bar";
Miért nem módosítható pl. az első elem? Egyáltalán lefordul? Ha igen/nem miért?
typedef struct foo *BAR;
struct x
{
char c;
BAR ptr;
};Lefordul?
struct x
{
char c;
int i;
} foo bar;Lefordul? Ha igen/nem miért?
Az enum teljesen mértékben portábilis?
Az elsőről már hallottam, de még soha nem használtam (nem kellett még). Bevallom derekasan a középsőről nem hallottam még. Az object (.o) fájl (és mellé kerülnek egyéb fájlok, mint pl. a nagyon hasznos .lst is) a következő lépcső a preprocesszált fájl után, ami gyakorlati értelembe vett fordtási szakasz. A header fájlok alapján kívülről elérhetők az egyesek függvények, tömbök, változók, és egyéb szimbólumok, amit majd később a linket fog összekötözgetni. A linker már teljesen független a nyelvtől. Szimbólumokat kötözgeti össze és közben persze figyelembe veszi az egyéb fordítónak szóló utasításokat, amivel mondjuk linkelés során tovább lehet optimalizálni, függvényeket elhelyezni a memóriatérben, összecsomagolja pl. a struktúrákat (__attribute__(packed)) stb... Kimenete a bináris/hex (Intel, Motorola, stb...), .map (memória térkép, meg lehet nézni hogy az egyes függvények és társaik hol találhatók), .elf (debuggoláshoz kell). Azt tudni kell, hogy a forítás során utasítani lehet hogy az egyes program blokkokat egy egységként kezelje, aminek az eredménye, hogy a szorosan összetartozó object fájlokat már a fordítás során összelinkelni .a-fájlá. Az optimalizálás hatékonyabb, hogy ha két körösen fordítunk, ahol az első körben csak kielemzi az optimalizálási lehetőséget, majd második körben további optimalizációs lehetőségeket keres, majd fordít. Bár a tudásom megkopott, mert jó ideje nem kellett ezzel foglalkoznom.
-
buherton
őstag
Valaki tud igazán durva C tesztet? Aminél még egy tapasztalt programozónak is vakarnia kell a fejét. Az a baj, hogy a neten találtam párat, de azok nem elég kemények. Lehetőleg ne a printf, fopen, fseek és társaira feküjdön rá, mert azt úgy sem használom, hanem a deklarálás, definiálás, inicializálás, pointerek legyenek lehetőleg.
Köszi!
.![;]](http://cdn.rios.hu/dl/s/v1.gif)
.
Továbbá leírtam azokat az eseteket is, amikben a példád elbukik. Mindezek ellenére csak azért is kötöd az ebet a karóhoz, hogy a goto rossz.
. Láttam már olyan architektúrát, ahol kiszámolta a proci 
.
Ú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!
- Valve Index VR Kit
- Uhh Lenovo ThinkPad P15 G2 Tervező Vágó Laptop -75% 15,6" i5-11500H 16/1TB RTX A2000 4GB /1 Millió/
- Esport PC - i5 13400F, GTX 1080ti és 16gb DDR5
- Ohh Lenovo ThinkPad P15 G2 Tervező Vágó Laptop -75% 15,6" i5-11500H 32/1TB RTX A2000 4GB /1 Millió/
- AZTA! HP EliteBook 840 G8 Fémházas Laptop Ultrabook 14" -60% i7-1185G7 16/512 FHD IPS Iris Xe
- ÁRGARANCIA!Épített KomPhone i5 13400F 16/32/64GB RAM RX 7700 XT 12GB GAMER PC termékbeszámítással
- ismét elérhető 3db - Sennheiser MOMENTUM 4 fejhallgatók
- Kingmax 1x2GB DDR2 800 RAM eladó
- ÁRGARANCIA! Épített KomPhone Ryzen 7 9800X3D 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- AKCIÓ! Apple Macbook Air 13" 2020 M1 8GB 256GB SSD notebook garanciával hibátlan működéssel
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest