- Szünetmentes tápegységek (UPS)
- OLED TV topic
- Asztrofotózás
- TKL formátumú, vezetékmentes "Fekete Özvegyet" dobott piacra a Razer
- 3D nyomtatás
- Gaming notebook topik
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Sony MILC fényképezőgépcsalád
- Milyen processzort vegyek?
- Kompakt vízhűtés
Új hozzászólás Aktív témák
-
buherton
őstag
válasz
alapz@j #4807 üzenetére
Header-guardnak hívják. Az ok, amiért létezik azaz, hogy egy forrásból akaratlanul is többször hívódhat ugyanaz a header fájl*, ekkor minden, ami az adott header fájl tartalmaz az többször fog szerepelni. Ennek a fordítók nem igazán szoktak örülni.
* például: source.c-nek szüksége van foo.h-ra és bar.h-ra, igen ám de a bar.h-nak is szüksége van a foo.h-ra
-
buherton
őstag
válasz
alapz@j #4796 üzenetére
Fordító speicifikus parancs/címke.
Például az avr-gcc-ben hogyha te egy karakter tömböt a flash-be akarsz letenni, akkor nem elég csak a const-t elérni, hanem külön meg kell mondani a fordítónak, hogy tegye oda (PROGMEM-et kell használni). De hogy a példánál maradjunk mostanában egy STM8-ra fejlesztek (a fordtó nevére nem emlékszem), ahol @-al kezdődő szavak fordító specifikus direktívák. Például, ha azt mondom a függvényre, hogy @near, akkor a lehető legközelebb fogja rakni a hívás helyéhez.
-
buherton
őstag
A memcpy-nál, hogy ha ugyanazon memória területen másolok, akkor az működőképes lehet? Hogy érthetőbb legyen itt egy példa:
memcpy(&foo[0], &foo[1], (sizeof(foo) - 1));
MOD: a szabvány ezt mondja:
memmove is required to work correctly even if the source and destination
overlap, while memcpy can assume non-overlapping operands and be optimized accordingly.Akkor a memmove az én barátom.
-
buherton
őstag
-
buherton
őstag
Az a baj, hogy ha beírod a gugliba, hogy ARM/NXP/ST/AVR/PIC development board-ra, akkor szívszédülést fogsz kapni az árak miatt. Egy kb semmit se tudó fejlesztő board 20-30-40-50k huf. Emiatt nagyon sokan adják a fejüket saját elkészítésére. Például. Viszont az való igaz, hogy elektronikát meg kell tanulni, mert enélkül hardveres problémákba ütközhet a programozó, mert itt mindent neked kell írni. Nincsenek driverek
. Kezdésnek ha megkérsz valakit, hogy építsen neked, akkor ilyen 10k huf alatti összegből kijössz. A hobbielektronika.hu-n jobban foglalkoznak ilyesmivel.
MOD: és OS sincs, ami ütemezné a taskjaidat
. Persze lehet ráírni.
-
buherton
őstag
Az uC-re úgy kell tekinteni, mint egy mezei digitális áramkörre kapcsolás tervezésnél. Ha speciális interfészeit akarod használni, akkor az adatlapban megtalálsz mindent. A legnehezebb a próba panel esetén, hogy mi kerüljön rá? Aztán a tervezés már nem probléma. Amit ajánlani szoktam az a 2-3 kapcsoló, 2-3 nyomógomb (természetesen Schmitt triggerelve), LCD kijelző, 2 7 szegmenses (ezt én shift regiszterrel szoktam meghajtani, amit aztán SPI-al hajtok meg), 8 LED, RS-232, I2C-s EEPROM, SPI-s hőmérséklet érzékelő, Egy LED az egyik PWM kimenetre, a másik PWM-re pedig egy Darlington-ba kötött transzisztor pár, 32 kHz-es kvarc az RTC-nek, egy poti az egyik ADC-re. Ha tud az uC USB-t, akkor értelemszerűen azt is kivezetm. Ahogy a kolléga mondta, minden uC lábat tüskesorozni kell. Ahogy látod ezenek a nagy része sima GPIO lábra kerül, csak az EEPROM, SPI és a soros port a speciális, mert azok kommunikációs lábakra kerülnek.
Tessék olvasgatni az adatlapokat.
-
buherton
őstag
válasz
Dave-11 #4753 üzenetére
Szia!
Az első és legfontosabb dolog az angol nyelvtudás. A nélkül csak a magyar fórumokra és cikkekre hagyatkozhatsz, ami nem túl sok.
El kell döntened, hogy hobbi célból vagy komolyabban szeretnél-e ezzel foglalkozni.
Ha komolyan akarsz ezzel foglakozni, akkor csak is az ARM jöhet szóba. Ezt csak ajánlani tudom, mert amit megírsz az menni is fog. Ezen kívül még annyi költség merül fel, hogy a perifériákat megvedd. A NYÁK-on minden elő van készítve, így ha pl. Ethernetet akarsz rákötni, akkor csak a csatlakozó kell. Az USB dettó. Van rajta minden ami kellhet. Sőt a debuggerrel bármilyen NXP ARM-t programozhatsz! Van hozzá gcc fordító fork, és egy Eclipse CDT IDE fork. Mind a kettő ingyenes.
Ha hobbi szinten szeretnél foglakozni, akkor három gyártó jöhet szóba. A Parallax, Atmel, és a Microchip. A Parallax-nak azaz érdekessége, hogy 8 mag van benne. Egyáltalán nem bonyolult, de sajnos saját nyelve van, illetve kevésbé ismert. Az Atmel és a Microchip nagyjából egyszinten van. Van amiben egy jobb, van amiben a másik. A hobbielektronikán elég sok hsz-n keresztül ment a flame war, hogy melyik a jobb.
Az Atmel-t választottam, mert nem vagyok fordítóhoz, és fejlesztő környezethez kötve. Ugyanis az AVR-nek ugyanúgy van gcc forkja, és azt bármilyen univerzális fejlesztő környezetben használni. LUFA project néven készült egy AVR ISP mkii klón, ami szinte teljesértékű a gyári programozóval. Továbbá az Atmel biztosította, hogy otthon is utána építhető lehessen az AVR JTAG, amivel már debuggolni is lehet a cuccot. A Microchip pozitívuma, hogy bárhol beszerezhető, és a PICkit 2 elég sok mident tud debuggolni. Ami viszont nem tetszik, hogy a fordítóval nincsenek jó emlékeim, és még gcc fork sincs belőle (nem véletlenül?), az IDE viszont nem rossz, de szinte esélyed sincs másikat használni annyira egybe integrálták az egészet. Ez is a PIC-el a legnagyobb problémám, hogy teljesen zárt. Nincs semmilyen szabadságod.
Bármi is legyen a döntésed a használt program nyelv a C legyen. Van Basic meg Arduino, meg mit tudom én mi, de az igazi beágyazott rendszer fejlesztő C-ben dolgozik, és ha a jövőben ebben szeretnél dolgozni, akkor ebben kell majd.
MOD: Az AVR-nél mindent meg lehet otthon építeni, de szerintem ugyanez vonatkzoik a Microchipre is. Ha drágállod a gyári megoldásokat, akkor érdemes az eBay-en körül nézni a klónok után
.
MOD2: Minden gyártó ad ki egy adatlapot a termékéhez. Abban minden fontosabb infót megtalálsz. Természetesen angolul íródtak. Rengeteg példa kód elérhető a neten.
-
buherton
őstag
Több példa is van, ahol a szabvány ezzel foglalkozik pl.:
sum = sum * 10 - '0' + (*p++ = getchar()); ennél a példánál sem egyértelmű, hogy mikor fog inkrementálódni a p mutató. Az okot nem írja csak a szekvencia pontokra hivatkozik.Az ilyenek valóban kerülendők, ezért sem találkoztam még soha ilyen warning üzenettel.
(#4747) Jester01: Sose próbáltam lefordítani, de ez tök jó, hogy a fordító figyelmeztet. gcc?
-
buherton
őstag
válasz
buherton #4730 üzenetére
Majd elfelejtettem.
Előre bocsátom, hogy ez az egyik legszemetebb teszt kérdés a C-ben. Ugyanis ehhez jól kell ismerni a C szabványt, mert abban van leírva, hogy "két szekvencia pont között ha egy változónak egynél többször adunk értéket, akkor nem definiált a működés", azaz nem tudjuk biztosra megmondani, hogy mi lesz az eredmény, mert fordító függő lesz.
Ismerősöm állás interjún kapott egy ilyen feladatot, de volt ám meglepetés, amikor elkezdte mondani a fentebbi szöveget, ugyanis az interjúztató nem tudott erről
. Így nem kell bánkódni azoknak akik nem tudták. Egy évvel ezelőtt én se tudtam volna a helyes választ.
-
buherton
őstag
A lényeg azaz lenne, hogy egy egyszerű mikrokontrolleres környezetet akartam kialakítani a PC-n, hogy ne a a hardveren kelljen szenvedni. Viszont nem rossz ötlet, csak kérdés, hogy Linux engedi-e, hogy egyszerre két program kezelje a soros portot (windowson biztosan nem), de ez már más topic.
-
buherton
őstag
A probléma egy kicsit összetettebb, mert az avr-gcc, ezt tudja:
static FILE mystdout = FDEV_SETUP_STREAM(usart_putchar_printf, NULL, _FDEV_SETUP_WRITE);
int main( void )
{
stdout = &mystdout;
printf("Hello world");
}
void usart_putchar_printf(char data, FILE *stream)
{
bájt küldése soros porton
}és ezt szerettem volna elérni a PC-n is, hogy végül egy függvényt hívjon minden karakter kiíráskor.
-
buherton
őstag
Lenne hozzátok egy teszt kérdésem saját felmérés céljából.
int i = 0;
i += i++;Mennyi lesz az i eredménye? A nagy tudású tudorok ne árulják el a választ
.
MOD: holnap ilyenkor adom meg a helyes választ.
-
buherton
őstag
válasz
don_peter #4728 üzenetére
A watchdog használata nem a kód minőségétől függ, hanem a életben előforduló véletlenektől. Ha biztosra szeretnél menni a programod működése szempontjából, akkor használsz watchdogot, mert nem tudhatod, hogy az adott eszköz milyen behatásoknak lesz kitéve, illetve mikor fog az uC tévedni. Ezekre a kihatásokra csak részben lehet felkészülni szoftveres és hardveres oldalról, és a watchdog sem jelent mindenre megoldást, de az legalább a nagy részét lefedi.
-
buherton
őstag
válasz
don_peter #4725 üzenetére
Örülök, hogy meg lett. Nem ez lesz az utolsó memória elírásod. Sajnos ez tapasztalat
.
Viszont ha már szóba került, akkor a watchdogot tényleg állítsd be. A watchdog egy speciális timer, ami ha lejár, akkor pl. csinál egy szoftver reset-et és ezzel újraindul az uC. Ez akkor jön jól, ha pl. viharban kap egy tüskét a cucc és beakasztja a futást. Ekkor a timer lejár és már reseteli is. Többféle alkalmazási technikája is van a WD-nek, de az általános azaz, hogy induláskor inicializálod a WD-t, majd valamelyik ciklikus "task"-ban reseteled a timer-t, ezzel megakadályozod, hogy lejárjon a timer.
-
buherton
őstag
válasz
don_peter #4711 üzenetére
Bocsánat, nem tudtam, hogy ilyen PIC-et használsz. Valamiért egy PIC16 rémlett. 32 kB flash, 2 kB RAM már jobban mutat.
Pár észrevétel:
- SSPCON1 regisztert illetve a társait valahogy el lehet érni bájtként, és akkor nem bitekkel kell majmolni. Nem mellesleg ha jó a fordító, akkor ezeket nem optimalizálja ki és mindenegyes sor egy 2 bájtos parancs.
- *pbuf++=spi_io(0x00); -> ez így elég meredek. Inkább így
for (i=0; i < PMEMBLOCK; i++) {
*(pbuf+i)=spi_io(0x00);
}
és már mehet is a const az argumentumba és biztonságosabb is így, mert a memória címe nem változik.
- while(!SSPSTATbits.BF); -> lehet ilyeneket használni, de akkor tegyél bele watchdogot (ez önmagában ajánlott), vagy timeout-t, mert ezek nélkül a jövőben okozhat problémát.Az a probléma hogy a for cikluson belül olvas ki több lapot, vagy a while cikluson belül?
-
buherton
őstag
válasz
alapz@j #4706 üzenetére
Miről van szó amúgy? ARM-nál szintek vannak meghatározva, ahol a supervisor mindent megtehet, de ha egy user szintű akar oda írni, ahova nem lenne szabad, akkor ezt hard fault expection-nel köszöni meg a proci. Azaz itt az architektúra tartatja be a szabályokat. Továbbá az MPU-nak meg lehet mondani, hogy ki hova írhat, de az megint egy másik tészta.
Nem mellesleg a C standard nem beszél ilyenről, így ilyen nincs. Az, hogy az OS vagy az architektúra támogatja-e az már a C-n kívül álló dolog.
-
buherton
őstag
válasz
don_peter #4698 üzenetére
Nem nagyon látok bele, hogy mi az ami készülődik, de két dolgot hozzá fűznék. 1. amit lehet azt tedd const tömbbe, mert flash-ből mindig több van, mint RAM-ból és még akkor is megéri ha egy kicsit bonyolultabb tőle a kód. 2. nem tudom milyen projekt keretében csinálod, de szerezz be egy nagyobb uC.
-
buherton
őstag
válasz
don_peter #4683 üzenetére
Nem a két hónappal van a probléma, hiszen valahol el kell kezdeni, hanem azzal, hogy a fél fórum gyakorlatilag ugyanazt szajkózza, de kötöd az ebet a karóhoz. Hidd el ezek a jelenségek, mint pl. függvények ugyanazt a változót használják és társaik általános jelenségek nyelvtől függetlenül, és erre vannak általános megoldások is.
Assembly-ztél már?
-
buherton
őstag
válasz
don_peter #4677 üzenetére
typedef enum
{
STATE_MENU = 0u,
...
} STATE_E;
static STATE_E menu_func(void)
{
//szükséges változók nullázása
//Sok sor program kód egy while() ciklusban pereg
// returnbe azt adsz vissza, amit akarsz
....
return STATE_PROFIL_LOAD;
}
main() {
STATE_E state = STATE_MENU;
while(1)
{
switch(state)
{
case STATE_MENU:
state = menu_func();
break;
case STATE_PROFIL_LOAD:
state = profil_load();
break;
}
}
}Ha nem akarod keverni a szezont a fazonnal, akkor az állapot gép függvényeit külön modulba is rakhatod, ahol modulra lokális változókat használsz, ha a függvények között szükséges az adatáramlás. Nem tudom, hogy mit akarsz csinálni, de a 2 kB borítékolhatóan kevés lesz, de szerintem még a 4 kB is. Gondolom valamilyen LCD-t is használsz. Egy frankón megírt LCD kijelző vezérlő is ~800 B, ami semmi extrát nem tud csak szöveget ír ki, de azt kényelmesen.
Nem vagy egy könnyű eset
.
-
buherton
őstag
válasz
don_peter #4641 üzenetére
Általában a char 8 bites szokott lenni, ami ugye 1 bájt (unsigned 0 - 255). A short int 16 bites, ami ugye 2 bájt (usnigned 0 - 65535). Az int 32 bites, ami ugye 4 bájt (unsigned 0 - 4 G).
Ha te egy unsigned char-ba teszel 256-t, akkor abban a változóban 0 lesz az értékadás után, mert átvitel fog képződni (signed esetén ezt túlcsordulásnak hívják). Ha te 255-nél nagyobb számot akarsz letárolni, akkor muszáj használnod a short int-et. Vagy char tömbbe is letárolhatod, és akkor rugalmasan lehet bővíteni. Például én most SPI-al akarok meghajtani 6 shift regisztert, ahol char tömbben tárolom le az egyes shift regiszterek bájtait.
Ismerkedj meg a struktúrával. Például:
typedef struct
{
unsigned short int temperature_min;
unsigned short int temperature_max;
unsigned char foo_bar[32];
} FOO_BAR_S; -
buherton
őstag
válasz
dabadab #4608 üzenetére
Szeretném én is kiegészíttetni a téma összefoglalót.
Magyar nyelvű könyvekhez:
Kónya László-Kopják József - PIC Mikrovezérlők alkalmazástechnikája [link]Fejlesztő környezetek:
Clang
cross-platform (Windows / Linux / OSX) csak fordítóMPLABX
cross-platform (PIC) fejlesztőkörnyezetEclipse CDT
fordítót nem tartalmaz, de konfigurálhatósága miatt szinte minden platforma minden fordítóval lehet benne fejleszteniLPCXpresso
cross-platform (NXP Cortex-M, ARM7, és ARM9 alapú mikrokontrollerek) fejlesztőkörnyezetAtmel Studio
cross-platform (AVR8, AVR32, Atmel ARM-ok) fejlesztő környezetarm-none-eabi
cross-platform (ARM Cortex-M és Cortex-R) csak fordítóEzek mind ingyenesen használhatóak. Az MPLABX-ben nem vagyok biztos.
-
buherton
őstag
válasz
sztanozs #4602 üzenetére
for(;fv(inputa()) || (fv(inputb()) - 1););
vagy
while(fv(inputa()) || (fv(inputb()) - 1));(#4590) Wyll: A fordító más megvilágítás alá helyezi a kódot, ha ternary operátor van benne. Ugyanez van a for(;;) és while(1) esetén is. Van olyan fordító ahol az utóbbinál tényleg érték ellenőrzés van. Ez mind fordító függő, illetve PC-n nem is kritikus ezzel foglalkozni, mert van bőven számítási kapacitás, illetve hely is.
-
buherton
őstag
válasz
Ereshkigal #4551 üzenetére
Memória szemét? Függvényen belül hozz létre egy auto típust, és ennek veheted a címét is.
-
buherton
őstag
válasz
don_peter #4532 üzenetére
Olvasd el az interrupt kezelést még egyszer, hogy tisztában legyél hogyan működik. A következő azaz, hogy a kiválasztott perifériának engedélyezni kell, hogy megszakítson, aztán engedélyezni kell a globális a megszakítást. Ha jól emlékszem, akkor elég buta megszakítás kezelője van, mert egy függényt hívogat mindig, és azon belül kell megnézni, hogy mely periféria flag-e állt be. Vagy lehet keverem egy másikkal? Nem akarok hitvitát indítani, de ez egy ritka rossz megoldása a megszakítás kezelésnek. Eddig 4 architektúrára fejlesztettem és ebből 3-nak azonos az elv, kivéve a PIC-ét, továbbá a FreeRTOS sem képes stabilan futni rajta. Ha javasolhatom, akkor inkább AVR, de még inkább az ARM Cortex-M0-t javaslom. Ez lenne a legjobb választás.
-
buherton
őstag
Eddig öt cégnél dolgoztam (négy autóipari, egy orvostechinkai) és különesebben nem kötötték meg sehol sem a fejlesztő kezét, hogy mennyire használhatja a nyelvi elemeket és szerintem ez így van jól. Persze legyen mellé rendes dokumentáció.
Sejtem, hogy melyik cégnél vagy, annak a kamionos részlegére majdnem bejutottam.
-
buherton
őstag
Ha szép kódot akarsz írni, akkor ott a C++. A C-t nem azért használják ma (kivétel természetesen a karbantartás), mert szép nyelv, hanem mert hatékony, de ha te ennek ellenére is szép kódot akarsz írni benne, akkor pont a lényeg fog elveszni. Például melyiket használnád egy szám kettővel való osztására?
value = (value >> 1);
value = value / 2;Az előbbi nem egyértelmű, hogy mi is a célja, de egy olyan architektúrán ahol nincs hardveres osztás ott csak ezt fogod használni, mert az előbbi 1 utasítás az utóbbi 10+ és még ciklus is van benne.
A kód autóiparban készült és egy másik mikrokontrollert figyel, hogy jól működik-e, és ha nem, akkor közbe avatkozik. Ha ezt nem tenné, akkor életre veszélyes helyzetek is könnyen elő állhatnak.
(#4491) axioma: eszmeletlen tomor kodot irt, ellenben kommentek nelkul, verziokezeles immel-ammal, es az o reszebe tkp. eselytelen volt masnak megtenni egy valtoztatast.
Meg is magyaráztad egy mondaton belül, hogy miért volt rossz ahogy fejlesztett. Dokumentáció volt hozzá? Design vagy hasonló doksi? Következő példád az emberi gyarlóságra vezethető vissza.
-
buherton
őstag
Bocsánat, de butaságot írsz. Erre való a komment, illetve a függvény, hogy a nehezebben érthető program részletet könnyebben át lehessen nézni. A szépen megírt kód nem hatékony, lassú, és több helyet foglal. Nagyon jó példa erre, hogy most ahol dolgozom ott súlyos összegeket adtak ki azért, hogy optimalizálják méretre a kódot, mert egyszerűen nem tudnak tovább haladni a fejlesztéssel. Tele volt nagyon szép, és könnyen olvasható kóddal, ami fölöslegesen foglalta a drága helyet. 20%-t hoztunk csak azon, hogy a szép kódokat és teljesen felesleges kód részleteket kigyomláltuk.
mert a shift es also bit szamolasanal se nem gyorsabb, se nem mellekhatas-mentesebb
Ha te mondod, de azért inkább maradok az általam kinézettnél.
Illetve pont attol hogy letisztultan szep, az latszik belole, hogy nem ott otolte ki az illeto, hanem valahol latta es megtanulta... ami megint nem az interjun vart kreativitast tukrozi.
Jah, hanem azt, hogy az illető szokott ilyen oldalakat is nézni, és foglalkoztatja annyira, hogy emlékszik rá. Ez tényleg üldözendő dolog.
Különben, ha nem tetszik, akkor itt van ez: int __builtin_popcount (unsigned int x), ennél világosabb nem lehet. Annyi probléma van vele, hogy nem fordító portábilis.
-
buherton
őstag
Csak egy kis érdekesség. Állásinterjún szokták az embert b.szogatni rövd C-s kódokkal. Ha valaki azt kapná, hogy írjon egy olyan programot, ami megszámolja, hogy számban hány bit van, akkor vessétek elébe ezt:
unsigned int count;
unsigned int num;
num = 1234;
for(count = 0; num; count++)
{
num &= - 1;
}Nem tudom hol láttam, de fellelhető a neten.
-
buherton
őstag
válasz
dabadab #4476 üzenetére
Most jött elő egy olyan probléma, amikor egy azon kód fut egy 8 bites architektúrán és PC-n is. Volt egy enum tömb, amit memset-el állítottak be valamilyen értékre. Viszont az enum egyik esetben 1 bájt a másik esetben 4 bájt, így ha nem nullát állítottak be, akkor jött a nem várt működés, mert a memset bájtokat állít és nem tömb elemet.
-
buherton
őstag
A fordító mi alapján dönti el, hogy az enum-ot hány biten ábrázolja? Feltételezve azt, hogy a legnagyobb szám 8 bit ábrázolható.
-
buherton
őstag
PC-n máshogy jön ki a dolog, de azért ne általánosítsunk. Qt-ban olyan kódot írhatsz ami GUI-t kezel és ugyanaz a függvény hívás három oprendszeren is működik. Csak külön le kell fordítani mind a háromra. Viszont beágyazott rendszerben nagyon kényelmes tud lenni, hogy PC-n kezdem el a fejlesztést, ahol ugye egyszerűbb debuggolni a C kódot és a memóriá elírásokat is nagyság rendekkel könnyebb megtalálni. Közre játszik ugye az is, hogy az elírásról az IC nem dob fel neked egy ablakot, hogy hoppá
. Amikor az ember túl van a nehezén csak áthúzza a másik projektbe és mehet a fejlesztés tovább a hardveren mindenféle változtatás nélkül. Ez a platform függetlenség. Persze ehhez mindkét helyen meg kell lennie a megfelelő interfész függvényeknek.
Vuze-val kapcsolatban rosszul emlékeztem akkor, de ettől függetlenül panaszkodnak rá, hogy jobban eszi a gépet, mint a többi torrent kliens.
(#4421) alapz@j: Szó mi szó nem szaggat nálam se, de a ventit nagyon pörgeti az fix.
(#4420) dabadab: C a beágyazott rendszerek egyeduralkodó nyelve. Ha újabb kocsid van, akkor nagyjából 10 millió sornyi C kód vigyáz rád, illetve szórakoztat téged
. Én személy szerint nem tanultam mást csak C-t. Ön szorgalomból tanultam meg a PERL-t, C++-t, egy kicsit a bash-t.
(#4437) alapz@j: Hogy a fenébe van ideje futás közben újra fordítani? Pontosítok. Honnan tudja futás közben, hogy hogyan lehet optimalizáltabb? Hogy tud még ennél is optimalizáltabb kódot fordítani?
-
buherton
őstag
válasz
alapz@j #4412 üzenetére
Nem szabvány szerinti függvény.Nálunk a C99 használatos.(#4413) alapz@j: A .NET alatt szinte mindeki a C#-ra gondol függetlenül attól, hogy nem csak abban lehet programozni.
(#4414) alapz@j: A C++ ahogy mondtad platform független, az hogy te mennyi függőséget viszel bele az már a te dolgod. Nem mellesleg a platform függetlenség alatt nem csak az OS-ek közötti átjárásra gondoltam hanem architektúra és rendszer váltásra is.
A Java pedig sajnos erőforrás igényes. Nézz meg egy Vuze-t (amióta átírták Java-ra azóta megy a panaszkodás, hogy nagy megterheli a gépet) vagy ott a Minecraft. Amilyen egyszerű a grafikája olyannyira erőforrás zabáló. A LibreOffice-ban sem véletlenül írják át folyamatosan a Java kódot C++-ra.
-
buherton
őstag
válasz
TheProb #4408 üzenetére
Amit írtál az mind OOP nyelv. Ha android, akkor Java. Ha windows phone, akkor .net, ha iPhone akkor objective C. A Java mellett szól, hogy mindenen fut, amin van Java virtuális gép, de lassú és sok memóriát igényel, és az Oracle-höz vagy kötve. A C++-ban teljes szabadság uralkodik, mert sem céghez, sem oprendszerhez, sem platformhoz nem vagy kötve, és annyira nem vészes. A .net alatt teljes zártság és kötöttség van. Viszont ha windowson kívül másra nem akarsz fejleszteni, akkor talán még ez a legjobb választás.
-
buherton
őstag
Mondjuk valahol igaz. Azért én is törekedni szoktam, hogy a warningok ki legyenek szedve a kódból.
De pl. a void main(void) warninggal nem szoktam foglalkozni, vagy a castos figyelmeztetésekkel.
(#4404) TheProb: Ha Androiddal fogsz foglakozni, akkor itt elég csak a túlélésért küzdeni. A C és Java ég és föld. Amit most csinálsz példát az Java-ban majd sokkal, de sokkal egyszerűbb és kényelmesebb lesz.
(#4406) TheProb: Függ attól, hogy mire programozol és hogy mit. Általában elmondható, hogy a Java egyszerűbb, és kényelmesebb. Rengeteg minden készen kapsz, amit a C alatt neked kell lekódolni.
-
buherton
őstag
válasz
TheProb #4401 üzenetére
Fel kell venni azt a bizonyos szemüveget, amivel a fontos és jelentéktelen warningokat ki lehet válogatni. Szerintem a strcat_s egy beépített függvény a VS-nek, így inkább javaslat lesz, mint valós warning. A standradban egészen biztosan nincs ilyen. Nem kell azzal foglalkozni. Függően attól, hogy merre szeretnél tovább tanulni én javasolnám a mingw (GCC) + eclipse kombót. A VS nagyon lekorlátoz. Gyakorlatilag csak PC-re és csak Windowsra tudsz fejleszteni. GCC + Eclipse-szel gyakorlatilag minden platformra tudsz fejleszteni.
IDE - Integrated Development Environment, a debuggerrel pedig lépkedni tudsz a kódban futás közben. Meg tudod nézni, hogy az adott változónak mi az értéke. Meg is lehet változtatni. Break pointokkal meg lehet állítani a program futását. Nagyon hasznos ha algoritmusbeli hibát szeretnél kidebbugolni.
-
buherton
őstag
válasz
superfinest #4288 üzenetére
Miért nem kezdesz akkor Java-val? Nem sok hasonlóság van a C és a Java nyelv között se. Ha megtanulod a C-t, akkor a Java-nál újra kell tanulnod még egyszer annyit, de inkább többet, mert teljesen más a paradigma. Bocsi de szerintem teljesen logikátlan, amit csinálsz. Ráadásul olyannal nyelvvel kezded, amire 99% az esély nem kell majd neked.
Én C-t tanultam, mert abban szerettem volna programozni, és abban is kell programoznom a munkahelyen.
-
buherton
őstag
válasz
superfinest #4284 üzenetére
Ebben nagyon is tévedsz. Az egy dolog, hogy a C++ visszafelé kompatibilis a C-vel, de ezzel nagyjából be is fejeződött a kapcsolat/hasonlóság. Döntsd el, hogy C-ben vagy C++-ban szeretnél-e megtanulni programozni, és a jövőben ne keverd a kettőt. Ha komolyan akarsz programozni, akkor a C++-t érdemes megtanulni.
-
buherton
őstag
-
buherton
őstag
válasz
tototos #4249 üzenetére
Az a baj a dinamikus memória használattal, hogy MPU nélkül nincs ki töredezettségmentesítse a memória táblát, és így előbb utóbb jön a hard fault exception, és jöhet a fej vakarás, hogy most ez mi a bánat volt, mert az RTOS-ek nem arról híresek, hogy szájbarágósan leírja, hogy mi történt (tapasztalat). Azt szokták csinálni, hogy előre lefoglalnak x memóriát, és arra írnak egy vezérlőt, ami karbantartja azt a területet, és ha kell akkor neked pointert, de ennek a technikai részletét nem ismerem. De mondom használj auto változót, vagy hát ha valaki másnak van jobb ötlete.
-
buherton
őstag
válasz
tototos #4245 üzenetére
Milyen mikrokontrollerről van szó? Van benne MPU? Ha nincs, akkor a malloc/free használata teljes öngyilkosság, és borítékolható a fagyás. Ha auto változóba tárolod le a stringet, akkor azt stackre rakja, ha jól rémlik.
MPU nélküli MCU-kban is lehet dinamikus memóriákat foglalni, de ahhoz neked kell a kezedbe venned a memória menedzsmentet. A mi projektünkben a kommunikációs driver pont így működik.
-
buherton
őstag
válasz
skylaner #4230 üzenetére
A fejlesztőt védeni kell az ilyenektől, mert ha meg van a lehetőség a bakira, akkor a fejlesztő élni fog vele, és fog ilyen hibát véteni. Ahogy lehet látni az error exceptionokon, és rengeteg memory leak-en, és nem véletlenül retteg mindenki az optimazációs szint lépéstől
, mert ilyenkor jobban összébb csúsznak a memóriában a dolgok, és igen hatékonyan eltudja rejteni a memória túl írásokat. A memcpy-nál meg tudod adni a méretet.
Nálunk új függvényeket csináltak erre, amivel biztosítva van, hogy a string mindig nullával végződik, így egy rakat hiba lehetősétől mentjük meg magunkat, de ettől függetlenül a hossz miatt még mindig vannak elírások akaratlanul is. Egy ilyen memória elírásnak a megkeresési ideje lehet 5 perctől 1 hétig terjedő idő, mert nálunk az OS nem árul el sokat, arról hogy hol történt a probléma.
-
buherton
őstag
válasz
Dave-11 #4223 üzenetére
Ezzel már letárolod a memóriában a tömböt: "Szia!", erről nyugodtan lehet kérni pointert, ahogy függvény argumentumként szokták is csinálni, de csak megkötésekkel.
1 év PERL után tértem vissza a C-re, és nagyon felidegesítettem magam, hogy mi a hét szentségért nem hajlandó benyelni a fordító ezt: char foo[10]; foo = "bar";
strncpy, és strncmp függvényeket használd, és figyelj mindig a \0 karakterre. Az strlen-t pedig kerüld amennyire tudod.
(#4224) Korcsii:
arra a MasterCard való
.
-
buherton
őstag
Áh értem most már.
(#4219) alapz@j: Nem op.rendszer függő, hanem architektúra. Az általunk használt ARM nem támogatja az MPU-t, így ha dinamikusan foglalsz memóriát, majd szabadítasz fel, akkor egy idő után teljesen széttöredezik a memória tábla, és lefagy az egész. De ha támogatná sem lehetne használni, mert automotive.
-
buherton
őstag
Szia!
Szerintem azért, mert sokan elfelejtik, hogy a realloc-nak a visszatérési értékét kell odaadni a pointernek. Ezt sokan elfelejtik, ugyanis ha új helyre másolja, akkor értelemszerűen a pointernek is változnia kell. Személy szerint nem tudom, hogy mi más probléma lenne ebből. Igaz, nálunk tiltott mindennemű dinamikus memória foglalás, mert ha használnánk, akkor a rendszer előbb utóbb lefagyna.
-
buherton
őstag
válasz
stranger28 #4193 üzenetére
Kiegészítés (#4195) dabadab hsz-re.
1. feleslegesek a typecast-ok és a jövőben kerüld ezeket, mert könnyen kerülhetsz olyan helyzetbe, amikor jön a fej vakarás, mert nem fut a kód, mint például:
void foo(long *bar)
{
*bar = 23424234;
}
int main(void)
{
char bar;
foo(&bar);
return 0;
}2. formázás: ez az adott sor végére rakni a { nem C-szerű formázás, hanem tán a Java-ból jön, és ajánlott ott használni. Továbbá próbáld kialakítani a saját stílusod, és tartsd magad ahhoz, mert könnyebb neked és másnak is olvasni a kódod.
int* foo; helyett int *foo; mert ebből is lehetnek gondok, mint int* foo, bar; és két pointer helyett lesz egy pointer és egy változó, és nincs olyan típus, hogy int pointer, hanem int-re mutató pointer van csak.
3. óvatosan az ilyenekkel:
for(i=0;i<n;i++)
if (palyak[i]==0)
{
nemsi_index[a]=i;
a++;
}Ugyanis nem feltétlenül portable a kód. Sajnos nem mindegyik fogadja el így ezt a formát. Az ilyen formával már kevésbé lehet gond:
for(...)
{
if(...)
...;
...;
} -
buherton
őstag
Default eclipse beállításnál is ilyen problémák vannak. Állítsd át a billentyűzet kiosztást
.
MOD: Ugye az angol billentyűzeten a speciális karaktereknek más hol van a helyük, így ők nyugodt szívvel tesznek ide billentyű kombinációkat.
-
buherton
őstag
Hát nem. Ez a példa lefordult, de másfélszer (igazából 10-szer annyit, csak faragtam rajta) annyi memóriát eszik mint amennyi van a mikrokontrollerben (1 kB van az MCU-ban), mert a nano részt is használja. Próbálkoztam az első példával, ami csak a pico-t használja, de úgy szó szerint egy rakás bug az egész. Olyan assembly parancsokat használ, ami nincs az AVR-nek, és ha azt javítom sem fordul le, mert két millió más baja van.
Pedig nagyon ígéretesnek tűnt, mert x86-on is lehet használni.
-
buherton
őstag
válasz
Jester01 #4092 üzenetére
Ha a linker szerint az ex_task4.o-ban is benne van, az azt jelenti, hogy huncutság van, például az ex_task4.c-ben lehet egy #include "ex_init4.c".
Ezt nem tudom, hogy honnan tudtad, de tényleg így van. Az ex_task4.c-ben semmilyen __heap_start-os declarálás, definiálás vagy hasonló sincs. De ez miért jelent problémát?
MOD: Arra gondolsz, hogy a make környezet úgy fordítja, hogy minden c fájt fordít, és ennek az lesz a következménye, hogy az ex_task4.c-ből includálva van az ex_init4.c ezért gyakorlatilag az ex_init4.c kétszer van fordítva? És amikor a linkeléshez ér, akkor jön a felismerés, hogy két __heap_start van, mert bár az ex_task4.c nem tartalmazza, de az include miatt mégis bele kerül.
(#4093) Karma: Igen, több példa is van, viszont úgy van megcsinálva, hogy a közös dolgok 4 init fájlban vannak, és a különböző példák ezeket include-álják és így egy rakat fölös kódot nem kell ismételten leírni. Ilyen a main, a task inicializálás, deklarálások, stb..-k. Nem túl szép, de az biztos hogy hatékony, de egyelőre még nem fordul...
-
buherton
őstag
Kezd nagyon felidegesíteni az Eclipse. A fordítás rendben lemegy. A problémák a linkelésnél jönnek elő. Hogyan lehet az olyan problémákat kiküszöbölni mint pl:
./ex_task4.o
.data+0x2): multiple definition of `__heap_start'
./ex_init4.o.data+0x2): first defined here
$ grep -R __heap_start
noscfg.h: * ::__heap_start and ::__heap_end must be provided and initialized
noscfg.h:extern void *__heap_start;
inc/pos_nano.h: * it is required to set the variables ::__heap_start and
Binary file Release/ex_init4.o matches
Release/PicoOS_task1.map: 0x000000000080006b __heap_start
Release/PicoOS_task1.map: 0x000000000080465b PROVIDE (__heap_start, .)
Binary file Release/ex_task4.o matches
Binary file Release/src/nano/n_mem.o matches
ex_init4.c:void *__heap_start = (void*) &membuf_g[0];
src/nano/n_mem.c: freeBlockList_g = (BLOCK_t)(void*)MEM_ALIGN((MEMPTR_t)(__heap_start));???
-
buherton
őstag
válasz
lockdown90 #4067 üzenetére
Nem. Így lesz helyes. Ugyanis a kiadási évet, és annak az indexét nem lehet egy változóban tárolni. Külön kell, mert a ciklusban a kiadási év a fontos, hiszen azzal nézzük meg hogy az adott könyv régebbi-e, de közben le kell tárolunk, hogy melyik volt ez, ami a végén szükséges.
N változó honnan jön? Használj inkább struktúra pointert, és mivel nem változik a struktúra, használj const kulcsszót (kettő is kell majd).
void kiir(nyil tomb[])
{
int i, minIndex;
int min=tomb[0].kiadev;
for(i=1; i<N; i++)
{
if(tomb[I].kiadev<min)
{
min = tomb(i).kiadev;
minIndex = i;
}
}
printf("Legregebbi konyv: %d\n Hozza tartozo cim: %s",tomb[minIndex].kiadev,tomb[minIndex].cim);
} -
buherton
őstag
válasz
PumpkinSeed #4009 üzenetére
Nem tudom kipróbálni, de ez lehet, hogy működik:
for(i = 0; i < 20; i++)
{
szam[i] = (int) szo[i]
} -
buherton
őstag
A szabvány elég egyértelműen fogalmaz:
It shall be defined with a return type of int and and with no parameters...
Vannak esetek, amikor lényegtelen, hogy van-e egyáltalán visszatérési érték, mert már a main függvény véget érése sem megengedett, mert nincs kinek megkapnia az értéket. Vélhetően ezekre az esetekre engedi a fordító, hogy void legyen a típus.
-
buherton
őstag
válasz
overclockerr #3936 üzenetére
Ha mérnök infó, akkor csak az ÓE. Onnan indult ez a szak és nem véletlenül.
Napi 1 óra semmi. Napi 1 órával egy C megtanulása 1 - 1,5 év. A java-é legalább 2-3 év. Főleg hogy a napi 1 óra se lesz napi 1 óra. Most 7 hónapon keresztül masszívan PERL-ezek (napi 6-7 óra), de még mindig látok új dolgokat.
-
buherton
őstag
válasz
Geresics #3935 üzenetére
Az ilyen vizsgáknak azaz átkuk, hogy csak kis esélye fogsz tudni átmenni úgy mint egyik volt szobatársamnak. Otthon megkapta a feladat megoldást, és megtanulta fejből. Azt nem tudta, hogy működik, de meg lett neki. Én ezt az utat nem javaslom.
Először keress egy C könyvet, és olvasd el kétszer legalább. Amint ez meg van gyere vissza ide.
-
buherton
őstag
válasz
buherton #3927 üzenetére
Itt van egy kicsit szebb. Bár a warning okát nem értem
.
#include <stdio.h>
#include <string.h>
int main(void)
{
int i;
char string[10];
char* sp = &string;
printf("Adjon meg egy max 10 karakteres szoveget\n");
gets(string);
while(*(sp++))
{
if(*sp > '0' && *sp <= '9')
{
int rep;
for(rep = 0; rep < *sp - '0'; rep++)
{
printf("%c", *(sp + 1));
}
sp++;
}
else
{
printf("%c", *sp);
}
}
printf("\n");
return 0;
} -
buherton
őstag
válasz
Geresics #3920 üzenetére
1. feladatra egy megoldás:
#include <stdio.h>
#include <string.h>
int main(void)
{
int i;
char string[10];
printf("Adjon meg egy max 10 karakteres szoveget\n");
gets(string);
for(i = 0; i < 10; i++)
{
if(string[i] == '\0') { printf("\n"); return 0; }
if(string[i] > '0' && string[i] <= '9')
{
int rep;
for(rep = 0; rep < string[i] - '0'; rep++)
{
printf("%c", string[i+1]);
}
i++;
}
else
{
printf("%c", string[i]);
}
}
printf("\n");
return 0;
} -
buherton
őstag
válasz
PumpkinSeed #3914 üzenetére
Conio vagy ncurses?
Készíts egy olyan progamot, ahol menüben lehet kiválasztani, hogy egy adatbázissal mit szeretnél csinálni.
Menü:
1. Adatbázis fájl beolvasása
2. Fájl mentése
3. Új adat felvitele
4. Régi adat törlése
(ez eddig 200 sor-ban meg lehet csinálni, tudom, mert már egyszer megírtam)
5. Adatok sorba rendezése -> lehessen választani mely oszlop szerint rendezzen sorba
Opcióként lehet benne csinálni formai ellenőrzést is, mint pl. dátumok helyes formátumban vannak-e megadva, megadott tartományon belül van az adott szám (lásd perc, óra, hónap, nap), névnek helyes-e a formátuma (nagy betűkkel keződik-e, van-e szóköz), stb...Ha ncurses, akkor készíts egy több ablakos UI-t, ahol ablakonként más és mást lehet csinálni, mint pl. egyik ablakban Fibonaccit kiszámoltatni, másikban a prímszámokat, másikban a tökéletes számokat, másikban a faktoriálist, stb...
Amiket írtam, azokat szét is bonthatod kisebb projektekre is.
Ajánlom a mi hamarabbi komolyabb programírását, mert ez a pár soros algoritmusokkal még nem fog az ember megtanulni, hogy hogyan lehet jól felépíteni egy nagyon hosszú programot.
-
buherton
őstag
válasz
PumpkinSeed #3911 üzenetére
Miért nem gcc-t, vagy mingw-t használsz? Parancssoros ablakban kiválóan lehet használni a ncurses-t, de ezt csak egy alternatíva
.
-
buherton
őstag
válasz
Jester01 #3838 üzenetére
Nem jogos, ha a C99 szabványt vesszük alapul, mert a 37. oldal 16 sorától:
The type signed char was introduced in C89 to make available a one-byte signed integer type on those systems which implement plain char as unsigned char. For reasons of symmetry, the keyword signed is allowed as part of the type name of other integer types. Two varieties of the integer types are specified: signed and unsigned. If neither specifier is used, signed is assumed.
-
buherton
őstag
válasz
PumpkinSeed #3835 üzenetére
Tudtommal nem igazán, csak nagyoltan, hogy ha 0 - 255 kell, akkor unsigned char, ha -128 - 127-ig akkor char stb...
-
buherton
őstag
válasz
buherton #3824 üzenetére
Ami kimaradt: így a get függvények belül egyik adattagot sem lehet írni, csak és kizárólag olavsni. Az set-get-es függvényeknek azaz előnyük, hogy szabadon lehet változtatni az összes adattagját, viszont get a függvénnyel egyesével tudsz értékeket olvasni. Kivéve ha nem kókányolsz íly módon:
#include <stdlib.h>
#include <stdio.h>typedef struct
{
int ifoo;
char cfoo;
} fooTypeDef;int get(const fooTypeDef * const foo, int * const ibar, char * const cbar)
{
*ibar = sfoo->ifoo;
*cbar = sfoo->cfoo;
}int main(void)
{
fooTypeDef sfoo;sfoo.ifoo = 10;
sfoo.cfoo = 'a';int ibar;
char cbar;get(&sfoo, &ibar, &cbar);
printf("%i %c", ibar, cbar);return 0;
}Vagy valami ilyesmi lesz.
-
buherton
őstag
válasz
tototos #3823 üzenetére
Olyat lehet csinálni, hogy senki nem írhat a struktúrába.
#include <stdlib.h>
#include <stdio.h>
typedef struct
{
int ifoo;
char cfoo;
} fooTypeDef;
int get(const fooTypeDef * const foo)
{
int i = sfoo->ifoo; //működnie kellene, ha csak ez van a függvény törzsben
sfoo->cfoo = 'd'; // erre viszont hibát kell, hogy dobjon, mert konstans változóba nem lehet írni
}
int main(void)
{
fooTypeDef sfoo;
sfoo.ifoo = 10;
sfoo.cfoo = 'a';
get(&sfoo);
return 0;
}Nincs nálam fordító, így nem tudom kirpróbálni, hogy tényleg működik-e.
Fene a jó dolgod. Szívesen foglalkoznék főállásban ilyennel, csak sajnos más fele vitt a sors. Most is körülöttem ilyennel foglalkoznak csak én más projekten vagyok.
-
buherton
őstag
válasz
tototos #3814 üzenetére
Röviden ennyi a set-get. Nem működik teljesen jól, de az elv jól látszódik. Mivel úgy írtad, hogy a sokból két változó nem változhat, így a const-os dolgot nem lehet használni, mert akkor egyik elemét sem lehet változtatni. Valamiért nem a 10-t tölti bele a változóba. Tudja esetleg valaki, hogy miért?
#include <stdlib.h>
#include <stdio.h>
typedef struct
{
int ifoo;
char cfoo;
} fooTypeDef;
void set(fooTypeDef foo)
{
foo.ifoo = 10;
}
int get(const fooTypeDef foo)
{
return foo.ifoo;
}
int main(void)
{
fooTypeDef sfoo;
set(sfoo);
printf("%i\n", get(sfoo));
return 0;
}Látom pointereket használsz. Ha azok sem változnak, akkor arra is ki lehet kötni, hogy konstans legyen.
MCU-ra vagy a PC-re írod a kódod?
Bocsi, hogy csak most válaszolok, de a munkahelyen nem szeretek 1-2 percnél többet foglalkozni a fórummal.
-
buherton
őstag
válasz
tototos #3812 üzenetére
Igen. Tulajdonképpen objektum orientáltan kell programozni C-ben, és ezt valahogy így tudod megoldani, hogy kávzi a struktúra az objektum paramétere, és a get/set függvény a metódusa.
De van egymásik lehetőség is, ami C-seb. Ha függvényekkel dolgozol, akkor amikor átadod a struktúrát, akkor const-ként kell átadni, mert nem akarod, hogy változtatva legyen (pointernél olyat is lehet csinálni, hogy a stuktúra címét ne lehessen változtatni). Így, mivel konstansként akarod használni a függvényen belül, és ne talán tán megváltoztatod az egyik értéket, akkor arra a fordító hibát fog dobni.
-
buherton
őstag
válasz
PumpkinSeed #3794 üzenetére
Tudtommal sehogy, csak mókolással. De hisz miért is kellene? A probléma inkább az szokott lenni, hogy a double kevés.
Kókányolni így tudsz:
float f = 1,23;
int i;
i = 10 * f;
f = (float) i / 10;Ez így nem biztos, hogy működik, de az elv az látszódik. Azzal hogy 10-el szoroztuk meg, a tizedesjegyet tudjuk átvinni, azzal hogy int levágja a tizedes veszző utáni részt, majd osztjuk 10-el.
-
buherton
őstag
válasz
PumpkinSeed #3755 üzenetére
Szerintem az ilyet ne algoritmusból próbáld megcsinálni, főleg hogy mások már megoldották. Ha Ubuntut használsz, akkor próbáld ki a terminálban a cal parancsot. C-ből szintén lehet parancsokat kiadni, de lehet, hogy kernelnek is van ilyen függvénye, amit csak szimplán meg kell hívni.
Vagy megírod C-ben: [link]
-
buherton
őstag
Egy napot kotlottam rajta, de ez nem jutott volna az eszembe... Persze hogy nem működik jól, hiszen ahogy írtad a két string címét kapja meg a struktúra, és az ugye mindhárom esetben ugyanaz, és mivel arra a két stringre legutoljára a Svájc került, így persze, hogy azt olvassa csak ki.
Ezer köszönet!
Igen csak szokni kell még a gondolkodást.
-
buherton
őstag
Sziasztok!
Nagyon régen programoztam C-ben, és az utóbbi több mint félévben csak és kizárólag perl-ben programoztam napi 8 órát. Most szeretném ismét elővenni a C-t, és ennek keretében egy sima adatbázis kezelést szeretnék írni, mert abban szinte minden fontosabb dolog érintve van.
A probléma writeFile függvényben van, mert mindig a struktúra legutolsó érvényes elemét írja ki i-szer. Nem pedig, a 0.-tól i-ig. Röviden a kód:
typedef struct
{
char *country;
char *capitol;
} twoCharArray;
int main(void)
{
twoCharArray db[20];
int validData;
if(readFile(db, &validData)) { return -1; }
if(writeFile(db, &validData)) { return -1; }
return 0;
}
int readFile(twoCharArray db[], intPtr validData)
{
int i;
for(i = 0; fgets(linebuff, 1024, dbFile) != NULL; i++)
{
split(firstPart, secondPart, linebuff);
db[i].country = firstPart;
db[i].capitol = secondPart;
printf("%s\t%s\n", firstPart, secondPart);
}
*validData = i;
}
int writeFile(const twoCharArray db[], const intPtr validData)
{
int i;
for(i = 0; i < *validData; i++)
{
concat(lineBuff, db[i].country, db[i].capitol);
printf("%s", lineBuff);
}
}
Ú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!
- HP ProBook 430 G8, 13,3" FHD IPS, I5-1135GU CPU, 16GB DDR4, 256GB SSD, WIN 11, 27% áfás számla, 1 év
- Playstation Portal - 3 hónap Bolti Garanciával
- BESZÁMÍTÁS! ÚJ AMD Ryzen 5600X 5700X 5800X 5900X processzor 3 év garancia 27% áfa termékbeszámítás
- BESZÁMÍTÁS! ÚJ AMD Ryzen 8500G / 8600G AMD Ryzen 7 8700G / 7800X3D processzor 3 év garancia 27% áfa
- Remek áron Lenovo ThinkPad x395 AMD Ryzen 7 pro-3700U/16GB/256 SSD/AMD Radeon Vega 10 Grap/FHD/IPS
- AKCIÓ! ASRock Z370 i5 8500 16GB DDR4 512GB SSD 2060 Super 8GB Zalman Z9 Plus Enermax 750W
- BESZÁMÍTÁS! Asrock H310CM i5 9400F 16GB DDR4 240GB SSD 1TB HDD RTX 2060 Super 8GB Zalman Z1 700W
- Csere-Beszámítás! Asztali számítógép PC Játékra! I5 12400F / RTX 3070 / 32GB DDR4 / 500GB SSD
- Azonnali készpénzes GAMER / üzleti notebook felvásárlás személyesen / csomagküldéssel korrekt áron
- Xiaomi Redmi 13128GB Kártyafüggetlen 1Év Garanciával
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest