Hirdetés
- 4K-s okosmonitor huppant le az MSI tervezőasztaláról
- Almás felhangokat pendít meg a Cougar legújabb, E-ATX-es háza
- A kelleténél jobban lebutítja egyes GeForce RTX 5090-es VGA-it a Zotac
- Komoly technikai frissítést kap a Grand Theft Auto V
- És akkor bevillant a nagy ötlet: miért ne lehetne hűteni egy tápcsatlakozót?
- Milyen monitort vegyek?
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- HiFi műszaki szemmel - sztereó hangrendszerek
- OLED monitor topic
- Multimédiás / PC-s hangfalszettek (2.0, 2.1, 5.1)
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Kormányok / autós szimulátorok topikja
- Apple MacBook
- Androidos tablet topic
- Milyen széket vegyek?
Új hozzászólás Aktív témák
-
Livius
őstag
válasz
buherton #6196 üzenetére
A National Instrument mérő hardverek 90%-a az Windows 10-re van komoly supporttal és driverekkel ellátva, ezért a saját CVI fordítójuk és IDE-jük volt sok 10 évvel ezelőtt már bevezetve hogy majd az jó lesz. Tehát nincs lehetőség, csak a Windows-ra, és sajnos az se nagyon könnyű eset, hogy az elavult C helyett mondjuk egy C#-ban történjen a GUI-s SW fejlesztés ebben a témában. A WSL2-öt amúgy ismerem, Yocto projectes Linux buildre már teszteltem, elég fasza kezd már lenni.
[ Szerkesztve ]
-
Livius
őstag
válasz
dabadab #6169 üzenetére
Én ilyenkor inkább így szoktam:
static int kvm_vcpu_check_block(struct kvm_vcpu *vcpu)
{
int ret = 0;
int idx = srcu_read_lock(&vcpu->kvm->srcu);
if (kvm_arch_vcpu_runnable(vcpu)) {
kvm_make_request(KVM_REQ_UNHALT, vcpu);
ret = -EINTR;
}
if (kvm_cpu_has_pending_timer(vcpu))
{
ret = -EINTR;
}
if (signal_pending(current))
{
ret = -EINTR;
}
srcu_read_unlock(&vcpu->kvm->srcu, idx);
return ret;
}Persze ekkor az nincs lekezelve, hogy a többi if-et kihagyja a returnbe érés előtt, ez kérdés szabad-e ebben a Linux driverben.
[ Szerkesztve ]
-
Livius
őstag
válasz
dabadab #6165 üzenetére
A mi C-ben írt CVI projektünkben egyelőre még ez a +10 év alatt jól volt kezelve az ilyen, hogy nincs szükség sehol calloc vagy malloc-ra és azok felszabadítására, tehát amit írsz példát nincs szükségünk rá nagyon, de ettől független láttam már benne go to-t olyan helyen, ahol csak a megértést nehezítette, de azt amit írsz előnyt semmit sem adott.
-
Livius
őstag
válasz
buherton #6163 üzenetére
Ez a coding style vagy coding rules az NI LabWindows CVI-ban programozott GUI-s projekthez kell (rémisztően csak C-ben lehet használni ezt a GUI-s frameworköt). Én eddig a neten mindenhol azt olvasom és azt tanították nekem, hogy a globális változó egy nagy programban már szigorúan kerülendő (itt már nem 8 bites microcontroller a cél HW), jelenleg ahova kellene az már egy nagy program, tele káosszal már sajnos. Valamint ELTE IK C/C++ gyakorlaton instant évismétlés járt a go to és continue használatért, és értettem hogy miért, miután egyszer valaha valami tele go to-zott programot kellett debugolnom, és visszafejtenem. Fenntarthatatlan és karbantarthatatlan lesz a program tőle.
Az Ericsson-os codechekker az Windwos 10-en is életre kelthető? Ez a CVI fordító és IDE csak Windows 10-en megy, ebben megy a napi munka.
[ Szerkesztve ]
-
Livius
őstag
Asztali PC-és C programozáshoz tudtok linkelni valami bevált nagy techcégek által is használt coding rules-t vagy coding style-t? A neten tele van minden +20 éves beágyazott rendszerekhez kitalált coding style-okkal, de nagyon nem olyan kéne, hanem ami inkább Windows PC-és környezethez van és C-hez azon belül is C99 vagy újabbhoz.
Olyan féle is jól jönne, ami nem csak a nevezéktanról ír, hanem általános programozási alapelvekről is, hogy pl kerüljük a globál változókat, meg tiltott legyen a go to használat stb.
-
Livius
őstag
Sziasztok!
Lenne egy Linux C/C++ programozási kérdésem, de lehet nem is annyira a C/C++ nyelv a lényeg benne, Linux kernel v4.x-et használok.A kérdés az, hogy amikor C/C++-ban a pthread.h-et használva indítok egy plusz threadet FIFO ütemezésben úgy, hogy előre attribútumban beállítom neki a CPU affinitást minden magra, a futás közben ezt a Linux hogy fogja figyelembe venni és kezelni? A thread amit indítok egy végtelen ciklusban figyelget egy thread-safe queue-t, és amikor van valami új elem azt kiveszi, majd csinál vele egy két műveletet, aztán megint blockolva várja a következőt. Ez a szál teljesen jól működik, kb 3-4%-os CPU használatot eredményez, de számomra nagyon gyanús az, hogy mintha a Linux véletlenszerűen indítaná az egyik magon a sok közül ezt a threadet, és utána örökké, csak azon a magon futtatja, vagyis a blockolás feloldása után mintha sose lenne olyan, hogy a másik magra kerülne át a futtatása, pedig a másik magon több szabad CPU idő lenne láthatóan htop-ban. Tud valaki valami infót vagy valami jó linket, hogy valami nagy könyv/biblia szerint a több magot is használható threadeknek hogy kéne managelődni a Linuxban a CPU magok között?
-
Livius
őstag
Akit esetleg érdekel, az ELTE-éről Porkoláb Zoltán C Programozás egyetemi előadása itt elérhető, folyamatosan kerülnek fel az új részek ebből a félévből! Elég sok link halott már a bevezetőben, ha esetleg frissíti majd valaki, talán ez is jó helyen lenne ott.
[ Szerkesztve ]
Ú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!
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- EA Sports WRC '23
- Mibe tegyem a megtakarításaimat?
- Politika
- Dune Awakening: Megjelenési dátumot kapott a PC-s kiadás
- Milyen monitort vegyek?
- Hardcore café
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- HiFi műszaki szemmel - sztereó hangrendszerek
- OLED monitor topic
- További aktív témák...