- Yettel topik
- Samsung Galaxy S22 Ultra - na, kinél van toll?
- Magisk
- Mobil flották
- Egy szenzor, két zoomkamera: újraírta a Huawei a mobilfotózás történetét
- Bemutatkozott a Poco X7 és X7 Pro
- Xiaomi 11 Lite 5G NE (lisa)
- Samsung Galaxy A56 - megbízható középszerűség
- Google Pixel topik
- Samsung Galaxy A55 - új év, régi stratégia
Új hozzászólás Aktív témák
-
G.A.
aktív tag
válasz
bucsupeti
#5296
üzenetére
Üdv!
Akkor nincs egyszerűbb megoldás, végig kell zongorázni a karaktereken?
Erre jutottam:
int line_count = 0, byte_count = 0;
byte[] TXBuffer = new byte[262144];
byte[] hex_data = new byte[262144];
string text = System.IO.File.ReadAllText(@"L:\stk500.hex");
string[] textSplit = text.Split(':');
foreach (string line in textSplit)
{
line_count++;
foreach (byte character in line)
{
TXBuffer[byte_count++] = character;
}
}
for (int i = 0, x = 0, temp; i < byte_count; )
{
if(TXBuffer[i] <= 0x39)
{
temp = (TXBuffer[i] - 0x30)*16;
hex_data[x] += (byte)temp;
}
else if (TXBuffer[i] >= 0x41)
{
temp = (TXBuffer[i] - 0x37) * 16;
hex_data[x] += (byte)temp;
}
i++;
if (TXBuffer[i] <= 0x39)
{
temp = (TXBuffer[i] - 0x30);
hex_data[x] += (byte)temp;
}
else if (TXBuffer[i] >= 0x41)
{
temp = (TXBuffer[i] - 0x37);
hex_data[x] += (byte)temp;
}
i++; x++;
}Este még nem működött, mert ezek hex_data[x] += (byte)temp; helyett ezt hex_data[x] = (byte)temp; írtam... Jól éreztem, hogy rá kellett aludni egyet.
bucsupeti: köszönöm a segítséget!
GA
-
bucsupeti
senior tag
végigiterálsz a sztringen karakterenként. a karaktert átalakítod 0-15 közti számértékké (ascii tábla tanulmányozása után egy egyszerű kivonás lesz az átalakítás) megszorzod 16-al, majd beolvasod a következőt számmá alakítod és az előző értékhez hozzáadod. ez lesz a tömböd első eleme. ezt a metódust folytatod amíg a végére nem érsz a sztringnek.
-
#5293
Fire/SOUL/CD
félisten
Reinkz
#5291
-
#5290
Reinkz
senior tag
Ereshkigal
#5289
Reinkz
senior tag
válasz
Ereshkigal
#5289
üzenetére
Nem ez sajnos nem tökéletes pl nagy ékeztes betűkkírása ugyan ugy nem megy vele, ha vki tudja mi a megoldás azt meg köszönném.
-
dabadab
titán
válasz
#36268800
#5285
üzenetére
Isten hozott a lebegőpontos számok világában!
Alapvetően két csúnya dolog van velük:
1. a pontosságuk korlátozott, vagyis előbb-utóbb lesznek kerekítési hibák
2. nem tizes, hanem kettes számrendszert használnak, így a tizes számrendszerben kevés tizedesjegyből álló számok simán lehetnek végtelen tizedestörtekHa kiíratnád a MAXP*0.57 értékét, akkor valószínűleg valami olyasmit látnál, hogy 0,57000001. Emiatt lebegőpontos számoknál számolni kell azzal, hogy az egyenlőség nem fog működni és nem egzakt egyenlőséget vizsgálni, hanem azt, hogy az adott szám benne van-e valamilyen tartományban.
-
#36268800
törölt tag
A C Példatár alapján írtam egy programot: link
0-100ig megadsz egy egész számot és megkapod az értékelést. (tudom, hogy a szám nincs vizsgálva hogy biztosan 0 és 100 közé esik-e, de tegyük fel, hogy igen)
Minden értékre jól működik, kivéve az 57-re.
MAXP = 100
MAXP*0.57 = 57Ha beírom simán a feltételnek, hogy 57 működik, ha MAXP*0.57-et adok meg, akkor viszont az 57 pontot "közepesnek" értékeli! Miért?
-
Karma
félisten
válasz
#36268800
#5279
üzenetére
Nem a double-int konverzióval van baj, sokkal nagyobb probléma, hogy a 34. és a 43. sorban a számítás végző függvényeket (pointerként) adod be a printf-nek, nem pedig meghívod őket.
A double kockázat megoldása annyi, hogy a 7. és a 14. sorban a hányadost 2-ről 2.0-ra átírod.
-
#36268800
törölt tag
Sziasztok!
Ezzel a kóddal kapcsolatban kérnék segítséget!
Az a része jól működik, hogy megmondja a program, hány megoldása van az egyenletnek, viszont csak 0.0000-kat ad vissza eredményül.
Gondolom a "double" - "int" részek kavarodnak, de már egy ideje görcsölök rajta és sehogy se jön össze. Valaki ki tudná javítani? Tanulnék belőle.
Ha nagyon nagy logikai hibák vannak a kódomban, akkor ne javítsátok ki, csak írjátok meg és megpróbálom összerakni máshogyan!!! -
fraba
aktív tag
(#5274) zka67
Igen, tudom, és az adatlapban is olvastam. A 750 ms az csak akkor szükséges, ha 12 biten ábrázoltatom vele a hőmérsékletet. Próbáltam belerakni 750 ms késleltetést __delay_ms(750);-el illetve szétdarabolva, pl. 200-200-as csoportokban. Le se fut ez a függvény(halmaz). Egyszerűen csak (mintha) átugorja, és küldi a többi mért adatot. Továbbá 16 C-nál magasabb hőmérsékleten tökéletesen működik a várakozás nélkül is. Szóval nem gondolnám, de persze lehetni LEHET!
(#5273) emvy
Erre én is gondoltam, hogy ez itt nagyon gyanús, hogy amikor 15-öt (00001111)-t kéne kijelezni, akkor 127 (11111111) jön helyette. De nem jutottam semmire se. Valami konkrét(abb) ötleted van?
-
fraba
aktív tag
Sziasztok!
Írtam egy DS1820 hőmérő IC-hez C-ben programot PIC-re, de sajnos nem úgy működik, ahogy kéne neki.
DS1820 kód. Jól és viszonylag pontosan mér, de 16 Celsius foknál kisebb hőmérsékleteknél 127 C-t jelez ki a putty egy USB-RS485 konverteren keresztül. Más, mért adatot is küldök ugyanezen a csatornán keresztül ugyanazzal a függvénnyel, így azt nem gondolnám rossznak. Valami ötlet?
-
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
-
dabadab
titán
válasz
EQMontoya
#5258
üzenetére
"Goto-t igazából a C korszakban igyekeztek nagyon írtani"
Valójában Dijkstra ismert cikke '68-as, a C-n meg '69-ben kezdtek el dolgozni Ritchie-ék, szóval a goto utálata megelőzi a C-t és igazából az a fajta vallásos utálat, ami bizonyos körökben megvolt a gotoval kapcsolatban, nem igazán volt indokolt.
-
válasz
Jester01
#5256
üzenetére
Ahogy irtam, generalt kod(kent indult).
Egyebkent meg a goto-val az a baj, hogy nagyon konnyu rosszul hasznalni. Maga a goto utasitas nem egy bun, alapvetoen. [link] (Egyebkent meg a compiler okossagatol fuggoen a while-continue lehet egy utasitassal lassabb, mint a goto..)
-
#5254
Sk8erPeter
nagyúr
EQMontoya
#5218
Sk8erPeter
nagyúr
válasz
EQMontoya
#5218
üzenetére
"ezt a hozzászólást már csak Lezsonak kell belinkelned, hogy c++ kulcsszóra miért nem találja meg a kereső"
Idézőjelek közé téve a keresőszót már megtalálja a kereső a topicot: [link]. A legtöbbször így kell itt kutatni a pontosság kedvéért (legalábbis ilyen jellegű keresőszavaknál biztosan), különben elég sok fura "valami hasonló" találat jöhet ki, ami valójában nem is hasonlít (mint pl. itt az idézőjelek nélküli változat).
-
kingabo
őstag
válasz
skylaner
#5252
üzenetére
Jaja. Nekem clipper kódot kellett portolnom igaz C#-ra. Fv első sora if akármi, az endif x ezer sorral lejjebb. Képtelenség volt átlátni, hogy mit csinál. Ha a működés fel lett volna osztva további fk-re, akkor szépen látszott volna minden lépés, hogy mit is csinál a cucc. (pl kérd le az adatokat, szűrd le, számolj velük, generálj exportokat, mentsd a változásokat)
Ráadásul, ha ügyesen bontad szét a működést és jó fv neket adsz igen nagy mértékben le lehet csökkenteni a kommentek mennyiségét. Nem kell kiírni, hogy most ezt csinálom azt csinálom, mert az fv nevéből látszik. A sokkal fontosabb, hogy miért csinálom kommentek (ami a sok komment között elveszik) pedig szem előtt lesznek, keresés nélkül is.
A C#-os region-okra egyre több helyen tekintenek rosszként. Github-on pl több helyen is írták, hogy egyáltalán ne legyen a kódban... Mellesleg amikor egy rakat kódot összefogsz egy régióba, azt akár ahogy van ki is rakhatod egy fv-be. És késöbb, ha bele kell nyúlnod könnyebben találod meg, könnyebb módosítani, sőt még a többi x helyre se kell a fixet copy-paste-elni, mert mindenhonnan fv-t hívsz.
Persze One-Man-Army esetén úgy dolgozol, ahogy jól esik, de ha másokkal kell együtt dolgozni, vagy más kódját kapod meg, amit először meg akarnál érteni, akkor (legalábbis számomra) mindenképpen hasznos, ha fv-kba szét van robbantva a kód és átlátható, mintha azt sem tudod az 1000 sorban hol is vagy éppen.
Sztem. -
válasz
dabadab
#5250
üzenetére
A k/q write only, akarhogy strukturalsz
Ha meg van code folding, akkor
#region Do something complex
do_something_simple();
do_something_even_simpler();
#endregionDe ha sima C-rol van szo, akkor igazabol nincs gyakorlati tapasztalatom real life, szoval elfogadom, ami mondasz.
-
dabadab
titán
"APL(-szeru) nyelven neztem bazi hosszu, teljesen strukturalatlan kodokat - ott ugye nem jellemzoek a fuggvenyek, viszont az sem, hogy regesreg krealt ertekeket hasznalsz sokkal-sokkal kesobb; inkabb sok-sok egymas utan kovetkezo es egymasra epulo lepest irnak le."
Azert ott is joval olvashatobb es kovethetobb lesz a kod, ha ugy nez ki, hogy van egy fuggvenyed, hogy
do_something_complex()
{
do_something_simple();
do_something_even_simpler();
// ...
}es az egyes lepeseket kirakod sajat fuggvenybe. A fordito meg ugyis inline-olja a fuggvenyeket, szoval meg csak lassabb se lesz.
-
válasz
dabadab
#5247
üzenetére
C/C++-ban tenyleg nem (amikor azzal dolgoztam, akkor maniakus overengineering ment a fejlesztes soran, es az kod nagy resze pure virtual osztalyokbol epult fel
), mas nyelvekben lattam hasonlot, de nem volt extra szenvedes, ez teny. (Es 40 agas switch/case szerkezetekkel se sokat talalkoztam, ez is teny; nem tudom, hogy ez szerencse, vagy tapasztalatlansag 
.)Mondjuk azert masrol beszelunk. En azt mondtam, hogy onmagaban a fuggveny hossza nem problemas, te meg azzal jossz, hogy ha nagyon bonyolult switch/case szerkezetek vannak, vagy a valtozok deklaracioja/ertekadasa es felhasznalasa kozott van 40 kepernyonyi kod, az problemas. Ezt elfogadom/elhiszem, de ugye itt nem a kod hosszaval van a gond -- a kod hossza az kovetkezmenye a problemanak, de nem az oka.
APL(-szeru) nyelven neztem bazi hosszu, teljesen strukturalatlan kodokat - ott ugye nem jellemzoek a fuggvenyek, viszont az sem, hogy regesreg krealt ertekeket hasznalsz sokkal-sokkal kesobb; inkabb sok-sok egymas utan kovetkezo es egymasra epulo lepest irnak le. Peldaul ilyen esetben semmi problema nincs a hosszu koddal.
De tenyleg nem tudok az erveddel vitatkozni
-
dabadab
titán
"Tehat vegulis az ok, amiert szet akarod szedni, az a konnyebb navigacio."
Nem csak a navigacio, hanem a fuggveny atlathatosaga is: ugyanis ilyen szerkezetnel siman elofordul, hogy olyan valtozokra hivatkoznak, aminek par szaz sorral korabban adtak valami erteket. (Ami IDE-kkel eddig talalkoztam, azok csak a komplett switchet tudtak osszehajtogatni, az egyes case agakat nem)
Bocs, de most tenyleg nagyon latszik, hogy soha az eletben nem kellett ilyenekkel szenvedned, azert nem gondolod ezt problemasnak
-
válasz
dabadab
#5241
üzenetére
Tehat vegulis az ok, amiert szet akarod szedni, az a konnyebb navigacio. Ennek a megkonnyitese szerintem az IDE dolga lenne, nem a programszervezese, es a modern IDEk mar szoktak tudni fold/collapse funkciot C++-ra is, ha jol gondolom. .Net-ben ott a #region pragma, ami pont erre valo; Java-ban a sok patternhuszar ugyis haromsoros classokba szervez mindent (
![;]](//cdn.rios.hu/dl/s/v1.gif)
), funkc. nyelvek meg altalaban tul tomorek ahhoz, hogy ilyen hosszu fuggvenyeket irjon az ember. -
dabadab
titán
"bar sokan azt valljak, hogy egy fuggveny ne legyen hosszabb X sornal, de ez szerintem butasag"
Ezt csak azert mondod, mert meg nem kellett olyan fuggvenyeket kibogoznod, amikor tobb ezer sor hosszuak voltak, bennuk tobbszorosen egymasba agyazott switchekkel, ami azt eredmenyezi, hogy a "hol vagyok a kodban?" kerdesre a valaszt tobb perces scrollozgatas adja meg.
Igazabol ha egy fuggveny kezd hosszu lenni (mittomen, tobb, mint szaz soros), akkor erdemes eltoprengeni azon, hogy nem lenne-e erdemes megis szetszedni. Erre persze lehet az is a valasz, hogy "nem", de azert toprengeni erdemes.
-
-
-
#36268800
törölt tag
Köszönöm a segítőkész válaszokat!
Újabb kérdésem lenne. Mindig is gondjaim voltak a függvények elkészítésével. Hogyan lehetne ebben a kódban azt a két adag feltételt 1-1 külön függvénybe kiírni, hogy ne a programtörzset árasszák el?
-
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)
-
dabadab
titán
válasz
#36268800
#5230
üzenetére
"A kérdésem az volna ezzel kapcsolatban, hogy mi a különbség az egyszerű "if" és az "else-if" között?"
Az, hogy sima if-eknél (megfelelő feltételek esetén) a program akár az összes if-be belemehet, if-else-eknél viszont legfeljebb csak egybe. Neked itt pont az else-if kell, mert egymást kölcsönösen kizáró feltételeid vannak.
"Esetleg valamelyik gyorsabban lefut?"
Ez is benne van, ha if-else-eknél belemegy valamelyik ágba, akkor utána a komplett blokk végére ugrik, nem nézi meg a többi feltételt. Mondjuk ez olyan különbség, ami tipikusan olyan kicsi, hogy mérések sem mutatják ki.
"A Microsoft Visual Studio-t használom, hol találom benne a program gyorsaságát?"
VS 2013-ban van profiler, de őszintén szólva nem hiszem, hogy jelenleg neked erre bármi szükséged lenne. Az ekkora programok futási ideje bőven mérési hibán belül van.
"Mi a véleményetek a kódom tagoltságáról?"
Így azért jóval olvashatóbb (ez az else-if szokásos írásmódja):
int main(void)
{
float num1, num2;
printf("Enter two numbers\nFirst: "); scanf("%f", &num1);
printf("Second: "); scanf("%f", &num2);
if (num1 == num2)
{
printf("They are equal: %f = %f", num1, num2);
}
else if (num1 > num2)
{
printf("They are not equal, %f > %f", num1, num2);
}
else
{
printf("They are not equal, %f < %f", num1, num2);
}
getch();
return 0;
}Ezen túlmenően ekkora kódnál azért különösebb tagoltságról nem lehet beszélni
ÁLtalános megjegyzésként még annyi, hogy lebegőpontos számoknál a == csak nagyon korlátozottan használható (itt mondjuk pont igen), mert ott a kerekítési hibák miatt előfordulhat, hogy két érték, aminek elméletben azonosnak kellene lennie, mégsem lesz pont ugyanannyi.
-
#5231
Ereshkigal
őstag
#36268800
#5230
Ereshkigal
őstag
válasz
#36268800
#5230
üzenetére
Az else ág csak akkor hajtódik végre, ha az if-ben szereplő állítás hamis volt. Mivel itt egymást kizáró feltételek vannak, lehet külön is írni az if-eket, mindig csak egy lesz igaz, így mindkét esetben azt csinálja a program, amit szeretnénk, de az if-else megoldás a jobb (nem vizsgáljuk mindig mind a három feltételt feleslegesen).
-
#36268800
törölt tag
Vetnétek egy pillantást a kódomra?
Itt a tutorial videó és itt az én kódom.
A kérdésem az volna ezzel kapcsolatban, hogy mi a különbség az egyszerű "if" és az "else-if" között? A fenti tutorial alapján készítettem el a kódot, de a srác az összes állítást külön "if"-ekként kezelte, én pedig egyetlen "if"-nek az "else" ágán mentem tovább.
Esetleg valamelyik gyorsabban lefut? A Microsoft Visual Studio-t használom, hol találom benne a program gyorsaságát? Mi a véleményetek a kódom tagoltságáról? (építő jellegű kritikát szeretnék kapni)
-
-
EQMontoya
veterán
válasz
Pttypang
#5222
üzenetére
Ejj, ha!
No, akkor okítsunk.
Először is: osztóJa!
Másodszor: szájbaszexuálnád a nevemben, aki arra nevel, hogy magyar változóneveket és függvényneveket használjatok?
Harmadszor: Optimalizáljunk:
-Ha a megadott szám kisebb, mint 1000, akkor elég a megadott számig menni. Tehát a ciklusfeltétel: i<min(n,1000). Illetve ennek is elég a feléig menni, mert különben ugyanazokat a számokat találod meg fordítva. Tehát i<=min(n,1000)/2. Azért kisebbegyenlő, mert kihasználtam gonoszul az egész osztást.
-Gondolkodjunk is: a második ciklus tök felesleges. Minden számhoz csak egy másik olyan tartozik, amivel összeadva az öszeg n lesz. Tehát, amit vizsgálnod kell: prime(i) && prime(n-i). Ezzel kész is vagy.Tehát:
for(i=1;i<=min(n,1000)/2;i++)
{
if(prime(i) && prime(n-i))
{
printf(...);
}
}No, ez már így nem is lenne rossz, most már cak a prímtesztelést kell kicsit okosítani. Maradjunk a primitív módszereknél, de ennél azért kicsit okosabban. Ha egy szám nem prím, akkor előáll két szám szorzataként. Ebből a kettőből az egyik kisebb, vagy egyenlő, mint a gyöke, tehát elég addig nézni.
Osztókat számolni tök felesleges, az első osztónál ugyanis biztosan nem lehet prím.Tehát:
for(i=2;i<=sqrt(n);i++)
{
if(!n%i) //csalok: ez akkor igaz, ha a maradékos osztás maradéka 0 - tehát osztható
{
return false; //van osztója, ami nem egy és nem önmaga
}
}
return true; //ha a gyökéig nem volt osztója, biztos prím.Máris mennyivel szebb, ugye?
-
-
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?
-
EQMontoya
veterán
válasz
buherton
#5213
üzenetére
Ebben a formában semmit, mert nem fordul le.
program.cc:6:1: error: expected unqualified-id before ‘int’
int b : 0,De ha kicseréli az ember pontosvesszőre...
Na, akkor sem fordul le, de a hibaüzi sokat elmond arra vonatkozóan, amit kérdezni akartál:program.cc:6:13: error: zero width for bit-field ‘<anonymous struct>::b’
int b : 0;De ha a b értékét 1-re módosítod ez után, akkor már egész jó a feladat.
-
#36268800
törölt tag
Sziasztok!
Most kezdem a C programozást és beleütköztem néhány (feltételezem bagatell) problémába a változók értéktartományaival kapcsolatban. A kérdéseimet összeírtam és szemléltettem egy táblázatban! Lennétek szívesek válaszolni rájuk? Szívesen fogadok olvasnivalót is!
Itt megtaláljátok a PDF állományt!
Köszönöm előre is!
-
buherton
őstag
-
EQMontoya
veterán
válasz
dabadab
#5204
üzenetére
Func ptr-t nyilván nem, nem is arra értettem.
Azért tegyük fel, hogy legalább minimálisab objektum-orientáltan kódolunk mátrixot, és annak műveleteit. Ott simán lehet írni inline-olt gettert.Egyébként teljesen jogos, de muszáj volt beletrollkodnom. Mint láthatod, nem csak bennem merült fel.
Illetve, ha már itt észt osztok, mai c++ lecke: egy argumentumos, POT-ot váró konstruktor legyen explicit, ha lehet.
Ha nem az, akkor olyan mókásságokba futhat bele a zember fia, mint egy rossz copy-paste után leforduló bool paraméterrel meghívott függvény, mint egy saját, file system path osztályt vár paraméterül. -
dabadab
titán
-
válasz
Jester01
#5200
üzenetére
> "Bizonyos mennyiség fölött garantáltan sokkal lassabb lesz, mintha ténylegesen transzponáltad volna."
Algoritmustol fugg. Ha kevesszer transzponalsz, de sokszor olvasol, akkor igen. Ha sokszor transzponalsz, es kevesszer olvasol, akkor a te megoldasod lehet drasztikusan lassabb. Ha pl. marha nagy matrixokkal dolgozol, de a transzponalt matrixot felhasznalo fel minden matrixbol csak nehany elemet vesz ki, akkor a lazy megoldas a jobb.
Főiskolás koromig egyáltalán nem foglalkoztam programozással. A BASIC-hez pedig elég fiatal vagyok (24). No, most már ezt is tudom 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
), mas nyelvekben lattam hasonlot, de nem volt extra szenvedes, ez teny. (Es 40 agas switch/case szerkezetekkel se sokat talalkoztam, ez is teny; nem tudom, hogy ez szerencse, vagy tapasztalatlansag 
.)
.
Ú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!
- One otthoni szolgáltatások (TV, internet, telefon)
- Milyen billentyűzetet vegyek?
- SD-kártyát vennél? Ezért ne csak a GB-ot nézd! – Tech Percek #9
- A fociról könnyedén, egy baráti társaságban
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Macron betiltatná az EU-ban a közösségi médiát a 15 év alattiaknak
- Gaming notebook topik
- Atomenergiával dübörögnek tovább az Amazon adatközpontok, SMR-ek is jöhetnek
- Luck Dragon: Asszociációs játék. :)
- Plazma TV topic
- További aktív témák...
- Apple Ipad 10.generáció
- Új HP Pavilion x360 14-ek Érintős hajtogatós Laptop Tab 14" -35% i5-1335U 8/512 FHD IPS Iris Xe
- RTX 4080 SUPER,16GB. Ryzen 7 7800X3D, 32 RAM Fury RGB! Garancia!
- Asztali PC , i7 9700K , RX 5700 XT , 32GB DDR4 , 500GB NVME , 1TB HDD
- Dell Inspiron 5406 2-in-1i5-1135G7 16GB DDR4 3200 512GB NVME 14" FHD Érintőkijelző W11Pro
- LG 32GS95UE - 32" OLED / UHD 4K / 240Hz - 480Hz & 0.03ms / 1300 Nits / NVIDIA G-Sync / AMD FreeSync
- Tablet felvásárlás!! Apple iPad, iPad Mini, iPad Air, iPad Pro
- MacBook, Apple M1 / M2 kompatibilis dokkolók, DisplayLink 4K, USB-C, Type-C
- AKCIÓ! ASUS MAXIMUS VIII HERO Z170 chipset alaplap garanciával hibátlan működéssel
- 35" ASUS ROG Swift PG35VQ curved GAMER monitor
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged