- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
Hirdetés
-
Megjelenési dátumot kapott a Star Wars: Hunters
gp A tervek szerint június elején végre befut a teljes kiadás mobilokra/tabletekre és Nintendo Switch-re.
-
Mindenki AI-t akar, már 2025-re is eladták a HBM chipeket
it Az SK Hynix jelezte: akkora a terjeszkedés az AI-szolgáltatások piacán, hogy 2024-re az összes, 2025-re közel az összes HBM chipet eladták.
-
Saját Redmi Note 13 Pro+ a világbajnok focicsapatnak (és indiai rajongóiknak)
ma Argentína nemzeti válogatottjának mezével díszítik az új Redmi különkiadást.
Új hozzászólás Aktív témák
-
jattila48
aktív tag
válasz dabadab #3250 üzenetére
A BSD API Windows-on is gyakorlatilag ugyanaz. Miért lenne, bonyolult jól megcsinálni a megbízható kommunikációt. A TCP arra készült, hogy megbízható legyen. Vagy mire gondolsz?
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
dabadab
titán
válasz jattila48 #3251 üzenetére
"Miért lenne, bonyolult jól megcsinálni a megbízható kommunikációt. A TCP arra készült, hogy megbízható legyen."
Ahhoz, hogy az ember programjában legyen egy jól működő kommunkációs layer, az, hogy egy TCP csomagot el tud küldeni az ember, még nagyon kevés.
DRM is theft
-
jattila48
aktív tag
válasz dabadab #3252 üzenetére
Miért lenne kevés? Ha az objektumot már szerializálta olyan formára, amit a másik oldal is megért, akkor nincs más hátra, mint a szerializált csomagot TCP-n átküldeni. De akár az UDP is elég lehet, ha a programozó maga épít e köré egy saját kis protokollt.
[ Szerkesztve ]
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
dabadab
titán
válasz jattila48 #3253 üzenetére
"Miért lenne kevés?"
Eleve implementálni kell valami protokollt, a socketek kezelése alapvetően nem thread-safe (meg ha az egyes műveletek azok is), hibák lekezelése, stb. Nézz meg akár egy szimple ftp szervert v klienst, hogy abban mennyi hálózati kód van, pedig csak TCP csomagokat küldenek meg fogadnak
DRM is theft
-
ToMmY_hun
senior tag
válasz jattila48 #3248 üzenetére
"ágyúval lövöldözés verébre"
Ezt jól látod, viszont egy sokszorosan tesztelt, sok ember által használt kódot felhasználni okosabb döntés, mint írni egy sajátot - az én tapasztalatommal legalábbis biztosan. Aztán az időnek is híján vagyok, van még egy hónapom befejezni a kódolást, szóval csak azt írom meg, amit muszáj. (Ez amúgy sem rossz stratégia)
Amúgy anno azért választottam a ZMQ-t, mert van Python és C++ variánsa is, így elég könnyű dolgozni vele. Bemegy a sztring C++ oldalon és a Pythonban megjelenik ugyanaz. A többi érvet, hogy cross-platform, cross-language és több kommunikációs modellt is támogat nem is sorolnám.
[ Szerkesztve ]
C programmers never die, they are just cast into void.
-
jattila48
aktív tag
válasz dabadab #3254 üzenetére
A protokoll maga a szerializált csomag. Ha ezt TCP-n (vagy UDP-n) átküldöd, a másik oldal ugyanúgy fogja értelmezni. Az mit jelent, hogy a socket-ek kezelése nem thread safe? A socket az nem egy globális valami, amit több thread egyszerre használ, hanem azt maga a thread hozzza létre saját magának. Másik thread másik socket-et hoz létre. Innentől kezdve természetesen thread safe. Ha a program jól van megírva, akkor nem fognak a thread-ek közös socket-et használni, így szinkronizációra sincs szükség. Ha arra gondolsz, hogy több thread ugyan annak a távoli partnernek akar adatot küldeni, akkor persze szinkronizálni kell az írást, de erről nem a socket tehet. Ezt bármilyen library-t használva is szinkronizálni kéne. Itt nem arra gondolok, mint pl. a web szerver esetén, amikor sok kapcsolat épül ki a klienstől a szerver felé, amiket külön-külön thread-ek saját socket-eken keresztül kezelnek, hanem amikor egy adott konnektált socketre akar több thread írni. Az ftp speciel nem annyira szimpla, mert pl. két TCP csatornát használ, aktív vagy passzív módban működik, hitelesít, stb. Maga az adatkommunikációja pedig szintén szimpla TCP. Nem csak néztem ftp kódot, hanem írtam is.
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
jattila48
aktív tag
válasz ToMmY_hun #3255 üzenetére
Végül is, te tudod... A tapasztalatom az, hogy sokszor érdemes az egyszerű problémát egyszerűen megoldani. Ha saját megoldást dolgozol ki, akkor mélyebben megérted a dolgok működését, és később jobban fogod látni, hogy a könyvtári megoldásoknak mik az előnyei, hátrányai, és érdemes-e alkalmazni egyáltalán. Másrészt ezeknek a kész könyvtáraknak az installálása, használatának megtanulása sokszor több időt/energiát emészt fel, mint ha megírod saját magad a kis problémádat megoldó kódot. Persze ha már ismered, akkor más a helyzet. Én pl. a boost-ról (de kicsit a protocol bufferről is) gondolom, hogy jó-jó, de amire használtam (asio) arra túl sok energiát pazaroltam el miatta. Ezek a könyvtárak (a boost főleg) sokszor erősen "túldizájnoltak" és marha nagyok. Belekényszerítenek egy olyan keretbe, ami nem feltétlenül jó az adott feladatra, és ez rengeteg plusz munkát jelent. (ez most nem flame akart lenni, pusztán vélemény!)
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
ToMmY_hun
senior tag
válasz jattila48 #3257 üzenetére
Részben igazad van. Az tényleg nagyon hasznos, ha megírja az ember saját maga tanulási céllal az ilyen, és ehhez hasonló problémákat megoldó programokat. Ezt majd én is szeretném megtenni, csak egy kicsit kevésbé túlhajtott időszakban. Abban is igazad van, hogy a könyvtár használat sem mindig jó. Pár hete jártam úgy, hogy egy céges kódban kiváltottam egy 3rd party library-vel egy nagyobb kódrészletet. Teljesen jól szuperált, örültünk is neki, aztán rá egy hétre hozzá akartunk adni egy új feature-t, amit viszont nem lehetett megoldani azzal a library-vel. A vége az lett, hogy vissza kellett hozni a kigyomlált saját kódot. Van ilyen is, főleg akkor, ha nincs fix specifikáció.
Azzal viszont nem értek egyet, hogy nehéz telepíteni/megtanulni őket. Az installálás nem volt vészes eddig egyik könyvtárnál sem. (Egyébként ez iszonyat jól meg van oldva Java-ban, ha érdekel nézz utána a Maven-nek). Általában annyiból áll, hogy le kell szedni a projektet, lefordítani és bemásolni a megfelelő mappákba. (ZMQ automatikusan installál is, szóval itt a kézzel másolgatás is megúszható). Ezután ugye linker-nek kell megadni a lib nevét, include-olni a header-t és készen is van. A használat már más kérdés. Sok esetben hiányos, vagy nem is létezik a dokumentáció. Azokkal nagyon nehéz bánni, de a komolyabbak - amelyek mögött nagyobb közösség áll - rendelkeznek megfelelő doksival. A használatának megtanulása pedig a doksin múlik. Egy lényegre törő, jól strukturált dokumentációból pillanatok alatt ki lehet szűrni a lényeget. A többi funkció meg nem is biztos hogy akkor, abban a pillanatban érdekli az embert.
[ Szerkesztve ]
C programmers never die, they are just cast into void.
-
jattila48
aktív tag
válasz ToMmY_hun #3258 üzenetére
Biztos van könnyen kezelhető könyvtár is, de sajnos van aminek az installálásától is lesz néhány ősz hajszálad. A boost-ot pl. azzal az adott fordítóval komplett buildelni kell, amivel majd használni fogod (több óra). Buildelés során hol ezt, hol azt nem talál, az SDK verzió nem jó, stb. Ha esetleg előre buildelt változatot használsz, akkor nem fog működni más verziójú fordítóval, a lefordított kód fut windows7-en de nem fut XP-n, könyvtárak és object fájlok verziói nem stimmelnek, nem lehet statikusan a programhoz linkelni, stb. Aztán jön a dependency walker, meg a szarakodás, hogy mégis mi a fene baja van. protocol buffer hasonló, kicsiben. De az OpenSSL-ből sem szokott jó lenni az előre buildelt. Amikor könyvtárat használsz (főleg template könyvtárat mint a boost), akkor erre is fel kell készülni.
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
dobragab
addikt
válasz jattila48 #3259 üzenetére
Ez nem a C++ libek telepítési nehézsége, hanem az összes Windows szegénységi bizonyítványa. Jól működő operációs rendszeren ennél kicsit egyszerűbb a dolog.
sudo apt-get install libboost-all-dev
A futtatáshoz szükséges binárisokat meg könnyebb beszerezni, akár Win, akár Linux, a Windows-ra fordításhoz ott a mingw-gcc cross.
[ Szerkesztve ]
Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.
-
ToMmY_hun
senior tag
válasz jattila48 #3259 üzenetére
Most hogy mondod jönnek vissza az emlékek. Anno Win 10-en kezdtem el a fejlesztést, aztán amikor eljutottam a Qt használatáig, rá kellett jönnöm hogy szívás van. Le kellett volna fordítani az MSVC2015-tel az egész Qt-t, hogy tudjam használni a saját statikus könyvtáramat, vagy a saját kódot kellett volna lefordítani olyan fordítóval, amiből már van Qt bináris. Egyik megoldás sem lett volna egyszerű. Qt-re majd kíváncsi leszek, de átpártoltam Debian-ra, és ezen neki mernék állni a fordításának is. Egyébként minden egyszerűbb rajta, szóval C++ fejlesztéshez ideálisabb, mint a Microsoft kacatjai.
[ Szerkesztve ]
C programmers never die, they are just cast into void.
-
jattila48
aktív tag
válasz dobragab #3260 üzenetére
Ez lehet, de ha speciel Windows-on kell vele dolgoznom, akkor nem vigasztal. Linux-on nem kell buildelni, nem függ a gcc verziójától, a lib-ek verziói is stimmelni fognak, vagy csak mindezt magától megoldja az apt-get? Azért Linuxon is szívtam én már hasonlóan (a boost-ot nem használtam).
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
jattila48
aktív tag
válasz ToMmY_hun #3261 üzenetére
"Egyébként minden egyszerűbb rajta, szóval C++ fejlesztéshez ideálisabb, mint a Microsoft kacatjai"
Ebben engedd meg, hogy vitatkozzak veled! A Microsoft VS kifejezetten jó IDE környezet, stabilitásban, használhatóságban nincs Linux megfelelője (szerintem!). A C++ fordítója is a legjobbak között lehet, bár nem mindig tartja be a szabványt. Generált kód minőségét (sebesség, méret, szabvány megfelelés) pedig a gcc-ét nem múlja felül egyik általam ismert fordító sem.
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
jattila48
aktív tag
válasz dobragab #3260 üzenetére
"Windows-ra fordításhoz ott a mingw-gcc cross"
A mingw-gcc valóban jó, de még kell rajta dolgozni. A Windows COM-mal pl. nagyon nem boldogul. A saját headereit sem mindig fordítja le. Különböző rejtélyes makrókat kell #define-olni (vagy preprocessor-nak definiálni), hogy rá vedd a fordításra. Több tízezer soros header-ek esetén ennek kiderítése igencsak strapás.
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
ToMmY_hun
senior tag
válasz jattila48 #3263 üzenetére
Használtam VS-t, és tényleg nem rossz - már amennyit én láttam belőle. Sajna olyat tapasztaltam, hogy corrupted lett egy bizonyos fájl (valami adatbázis) és emiatt nem engedte elmenteni az általam frissen létrehozott fájlokat. Persze ez nem olyan vészes, letöröltem a fájlt, újragenerálta és rendbe is jött. Az IntelliSense és a debugger/profiler frankó.
Java-hoz rengeteget használom a NetBeans-t és kipróbáltam C++-hoz is, azzal is ügyesen bánik. (Linuxon legalábbis, Win-en a compiler beállítással kínlódni kell). A fejlesztést sok eszközzel támogatja, amiket próbáltam és mennek: kódkiegészítés, debug, refaktorálás, library kezelés, CPP Unit test, Git addon (linuxon fontos). A profiler-re még kíváncsi vagyok, lesz olyan kódrész amit megnézek vele - feltéve ha van és működik.
MinGW gcc: thread-eket támogat? Ősszel próbálkoztam vele, és akkor azt olvastam hogy nem annyira, persze lehet hogy én voltam suta.
[ Szerkesztve ]
C programmers never die, they are just cast into void.
-
dobragab
addikt
válasz ToMmY_hun #3265 üzenetére
Mingw-gcc frankón bánik a threadekkel, hiszen betartja a szabványt: és a C++11 szabványban minden van, ami a multithreading-hez kell.
(#3263) jattila48
VS2015 mint IDE zseniális, ha lehetne mingw-vel használni, tökéletes lenne, de tök más a fordító paraméterezése, max. Intel compilerre tudnám cserélni. Az MSVC meg kritikán aluli.
C++ fordítója is a legjobbak között lehet, bár nem mindig tartja be a szabványt.
Remek, ezzel a legfontosabb kritériumot bukta. Azóta nem voltam hajlandó használni, amikor egyszer C-ben egy három paraméterrel előre deklarált függvényt egyetlen paraméterrel hívtam, és lefordult Adott warningot, de akkor is, ez mi?
[ Szerkesztve ]
Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.
-
jattila48
aktív tag
válasz dobragab #3266 üzenetére
VS használható mingw-gcc-vel. Próbáld ki a VisualGDB-t. 30 napos teljes értékű próba verzió, utána fizetős (nem túl drága). Vannak még hibái, de egész jó. Az MSVC-nél én is találtam olyat amit le kellett volna fordítania, de mégsem tette (ezeket itt meg is tárgyaltuk). Amit "többet" tud mint a szabvány (microsoft extensions), arra adhat warning-ot, vagy hibát, vagy semmit (beállítható). Ilyen pl., hogy temporális értéket megenged nem const lvalue referenciához kötni (szabvány szerint csak const lvalue vagy rvalue referenciához lenne köthető).
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
-
ToMmY_hun
senior tag
válasz EQMontoya #3269 üzenetére
Megnéztem, hogy NetBeans-ben milyen lehetőségek vannak.
Szimbólum keresés - Nem tudom pontosan mit értesz alatta, keresés projekten belül akármire lehetséges.
felhasználások megkeresése - Find Usages menü, kilistázza az egész projektben hogy hol van használva a keresett elem.
átnevezés egy gombbal - Refactor / Rename, kilistázza a találatokat és átnevezés előtt checkbox segítségével választható ki, hogy hol és mit szeretnél átnevezni.
autocomplete - Van, és nem csak kódkiegészítő, hanem a dokumentációt is mutatja.
beépített profiler - Ez sajnos nincs, legalábbis gyors keresés eredményeként ezt olvastam.
frankó debugger - Egy szálon futó programmal teszteltem, azzal minden fontosabb követelményt teljesített.
[ Szerkesztve ]
C programmers never die, they are just cast into void.
-
dabadab
titán
-
g@bo
nagyúr
hi
milyen könyvet ajánlanátok c++ nyelv kezdő elsajátítására?
-
Ereshkigal
őstag
Ha megy az angol: http://www.stroustrup.com/Programming/
-
EQMontoya
veterán
egy kezdonek a C sem egyszerubb
De.A függvények ugyan nem kellenek (csak egy részük), de a szemlélet nélkül, amit adnak, szívás lesz a C++.
Felőlem aztán mindneki úgy szopatja vele magát, ahogy jól esik, végülis nem élek még olyan rég C++-ból, hogy belepofázzak.Same rules apply!
-
doc
nagyúr
válasz EQMontoya #3290 üzenetére
Amellett hogy nyilvan elfogadom hogy masnak az enyemtol eltero a velemenye, nem ertek egyet
A C nagyon keves es nagyon kenyelmetlenul hasznalhato eszkozt ad a programozonak. Nincsenek ertelmes adatszerkezetek, nullarol kell mindent megcsinalni. A stringkezeles gyalazatos, kb mindenre csak a legalacsonyabb szintu fuggvenyek leteznek, ha vannak egyaltalan.
A 'szemlelet' amit a C-s fuggvenyek adnak kenyelmetlen es idejetmult, a C++-hoz meg kb semmi koze sincs, igy ugrodeszkanak hasznalni csak akkor erdemes ha az ember eleve akar C-vel is foglalkozni.
Azok a feladatok amik C-ben egyszeruen megoldhatoak C++-ban sem bonyolultabbak vagy nehezebbek, forditva viszont egyaltalan nem biztos hogy igaz.
En szeretem mindket nyelvet es van ahol a C++ nem is alternativa, de altalanos nyelvkent a C++ sokkal konnyebben es jobban hasznalhato mint a C.
egy kezdonek a C sem egyszerubb
De.Szerinted mi az amit kezdokent C-ben egyszerubb mint C++-ban? (foleg hogy a C++ az kb 99.9%-ban felulrol kompatibilis a C-vel)
-
EQMontoya
veterán
Szerinted mi az amit kezdokent C-ben egyszerubb mint C++-ban? (foleg hogy a C++ az kb 99.9%-ban felulrol kompatibilis a C-vel)
Az, hogy C++-ban kb. minden olyannal foglalkozol, amivel C-ben, de ha C-vel kezdesz, akkor nem egyszerre fogsz belezavarodni a referenciákba, pointerekbe, smart_ptr-ekbe és az érték szerinti átadásba, hanem csak a felé kapod egyszerre az arcodba.
Továbbá nem fogsz kapásból belefutni mondjuk a vptr-be, hanem lesz már némi fogalmad a függvénypointerekről, el tudod képzelni, hogy hogyan is működik az egész.[ Szerkesztve ]
Same rules apply!
-
ToMmY_hun
senior tag
C-vel kezdtem és sokkal könnyebb, mint C++-ban programozni. Alapozni nagyon ideális. Szerintem maga az OOP programozás nem kezdő téma, legfőképp nem C++ segítségével. Én még kezdő C++ programozó se vagyok, van OOP és C tapasztaltom is, de még így is azt mondom, hogy nem egyszerű. Feltéve ha jól akar benne programozni, alibizni bármiben lehet. Amennyiben mindenképpen OOP a cél, akkor Javat javaslom, sokkal letisztultabb, kezdő számára ideálisabb. Ahhoz van jó könyv is, méghozzá az Agyhullám Java.
[ Szerkesztve ]
C programmers never die, they are just cast into void.
-
doc
nagyúr
válasz EQMontoya #3292 üzenetére
Mitol kene ebbe 'belezavarodni'?
Miert zavarodsz bele a pointerbe ha C++ tanulas soran talalkozol vele, es miert nem ha ugyanazt C-tanulas kozben tanulod meg?A referencia a pointerek utan nem egy nagy truvaj, a smart_ptr meg mar egy olyan feature ami C-ben nincs (tehat neked kell nullarol megcsinalni), C++ -ban meg keszen kapod. Raadasul az mar eleve nem kezdo anyag.
-
g@bo
nagyúr
jó kis balhé lett urak... de valahol el kell kezdeni.
-
doc
nagyúr
válasz ToMmY_hun #3293 üzenetére
Az OOP valoban tok mas gondolkodasmod, mar csak ezert sem tartom jo otletnek csak azert C-t tanulni hogy utana C++-ozz. A C megtanit egy adott, strukturalt modon gondolkodni amit az OOP-nal kb. dobhatsz is ki, mert teljesen mas a megkozelites.
En is C-vel kezdtem, es C++-ra valtva nagyon sokaig gyakorlatilag C-ben progamoztam C++ szintaktikaval
Nehez volt atszokni az OOP-re, nagyon visszahuztak a C-s szokasok.Abban megintcsak egyetertek hogy ha a cel egy barmilyen OOP nyelv akkor a C++ elsore nem egy jo valasztas.
-
-
doc
nagyúr
válasz ToMmY_hun #3298 üzenetére
mennyivel nehezebb a pointer fogalmat megerteni C++ tanulas kozben mint C tanulas kozben? nyilvan semmivel, pontosan ugyanarrol van szo mindket esetben
valamiert meg vagytok gyozodve arrol hogy aki C++ -t tanul az nem tanul tombokrol meg pointerekrol, mig aki C-t tanul az igen, holott mindket esetben ugyanugy, es ugyanott resze az ismeretanyagnakA kulonbseg hogy amikor eloszor irsz egy tombelemeket ciklusban kiiro kodot akkor nem mondjuk printf("%d\n", arr[i]) hanem cout << arr[i] << endl lesz a kod. A lenyeg, vagyis a ciklus pont ugyanaz lesz mindket esetben.
Amikor pointerekrol tanulsz, akkor meg plane ugyanaz lesz, ugyanugy kell dereferalni mindket esetben, ugyanugy kell megerteni hogy hogyan 'mutat' a pointer a mogotte levo adatra.
Amikor mar benne vagy a surujeben akkor a C++ mar nyilvan bonyolultabb lesz, de ott meg pont nem segit semmit ha a C-specifikus dolgokat tudod (sot, csabit a durva ganyolasra C-s modszerek hasznalataval, lattam mar ilyet...)
[ Szerkesztve ]
-
dabadab
titán
válasz ToMmY_hun #3293 üzenetére
"C-vel kezdtem és sokkal könnyebb, mint C++-ban programozni. Alapozni nagyon ideális."
Meg arra is, hogy rossz szokásokat vegyél fel, szoktam azzal baszogatni a kollégákat, hogy amit írnak, az C, nem C++, szóval az így nem lesz jó
Pointereket meg hasonló alacsonyszintű dolgokat szerintem assemblerben sokkal jobban meg lehet tanulni
Az eredeti kérdéshez sajnos érdemben nem tudok hozzászólni, a kézenfekvő válasz a Stroustrup-féle C++ aktuális kiadása lenne, de azt is csak a polcon van meg, valahogy soha nem jutottam el odáig, hogy el is olvassam.
[ Szerkesztve ]
DRM is theft
Új hozzászólás Aktív témák
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Házimozi, és Hifi kábelezés!
- Elektromos rásegítésű kerékpárok
- Xbox Series X|S
- Mindenki AI-t akar, már 2025-re is eladták a HBM chipeket
- plevips: Építkezünk 3. rész (2024)
- World of Tanks - MMO
- Proxmox VE
- Kerékpárosok, bringások ide!
- Spórolós topik
- Autós topik látogatók beszélgetős, offolós topikja
- További aktív témák...
- XFX RX 6600 XT SPEEDSTER SWFT 210
- AKCIÓ Új Dobozos Macbook Pro dokkoló új ára 70.000 forint
- ThinkPad Hybrid USB -C USB -A Dock 40AF Új ára 80.000 Forint Ingyen szállítás
- Xiaomi Redmi Note 9s 128/6 GB 34.9E !!!
- Új Hp Pavilion 15-eh Fémházas Szuper Laptop 15,6" -30% AMD Ryzen 7 5700U 8Mag 16/1TB FHD MATT
- Új állapotú.11.Generációs Core i3-Lenovo Laptop-Magyar-Legolcsóbban-fél év garival.
- Huawei P20 Pro Kártyafüggetlen hibátlan telefon
- TOP PC konfig /i7 14700K, 32GB DDR5 RAM, 1TB Gen4 SSD/ szuper akciós! BeszámítOK
- Linksys EA6900
- DELL OptiPlex 3040 SFF / i3-6100 - i5-6500 - i7-6700 / HDMI / DVD-RW / több db / 27% áfás számla