- Samsung Galaxy A55 - új év, régi stratégia
- Yettel topik
- Honor 200 - kétszázért pont jó lenne
- Honor 200 Pro - mobilportré
- Youtube Android alkalmazás alternatívák reklámszűréssel / videók letöltése
- Huawei Watch GT 5 Pro - egészség + stílus
- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
- iPhone topik
- Apple Watch
- Mi nincs, grafén akku van: itt a Xiaomi 11T és 11T Pro
Új hozzászólás Aktív témák
-
alapz@j
tag
válasz
jattila48 #6331 üzenetére
Ezt írtam rá tegnap:
void t1(void) {
char msg[16];
strcpy(msg, "Hello!");
puts(msg);
}
void t2(void) {
char msg[16];
puts(msg);
}
int main(void) {
t1();
t2();
return EXIT_SUCCESS;
}Mivel a t1 és t2 függvényeknek ugyanolyan méretű a kezdeti stack frame-je, így a t2 hívásakor a char[16] ugyanarra a memóriaterületre esik és a puts szépen kiírja az előző függvényből ott maradt Hello!-t
-
alapz@j
tag
Én magam is leadnék egy szavazatot a goto és az early return mellett :) közben pedig bedobok egy lehetséges megoldást a fentebb is vázolt hibakezelés közbeni erőforrás-deallokálási problémákra, sajnos csak a GCC fordítót használóknak:
void free_buffer(char ** buffer) {
free(*buffer);
}
...
char *buffer __attribute__ ((__cleanup__(free_buffer))) = malloc(20);
Amikor a buffer kimegy a scope-ból, auto meghívja a cleanup attribútumban megadott függvényt.
http://echorand.me/site/notes/articles/c_cleanup/cleanup_attribute_c.html -
alapz@j
tag
válasz
Domonkos #5928 üzenetére
Emlékeim szerint a C szabványban nem szerepel, hogy a char előjeles vagy előjel nélküli lenne, ezt ráhagyja az implementációra. A fordítók pedig jellemzően az int és társai után a char-t is előjelesként kezelik alapértelmezetten, nem véletlenül vannak a -funsigned-char kapcsolók és társaik..
-
alapz@j
tag
A Nuwen.net-es MinGW-ben például van pcre / regex.h, nem kell hozzá Cygwin. Ne terjesszünk már olyan butaságokat, hogy a "A C-t nem a windows-ra találták ki."!
-
alapz@j
tag
válasz
DasBoot #5764 üzenetére
Gyakran jönnek ide (és nyilván más hasonló fórumokra is) olyan emberek, akik a tökéletesen nulla szintről (lásd: hová írjam a printf()-t) szeretnének megtanulni programozni és ezt úgy képzelik, hogy majd itt sorról sorra elmagyarázzák nekik a profik. Ez nem működik. Csak akkor tudunk segíteni, ha már legalább az olyan alapfogalmakkal tisztában vagy, mint forráskód, fordító, változó, stb. - és ezt nem lehet kérdezz-felelek formában elsajátítani.
Itt van egy teljesen kezdőknek készített C tutorial (environment setup, basic syntax, stb.), innen el tudsz indulni, és ha valahol elakadtál, biztosan lesz valaki ebben a topikban, aki segíteni fog:
-
alapz@j
tag
válasz
DasBoot #5758 üzenetére
Emlékeim szerint a kompájlerrel egybecsomagolt CodeBlocks-ot nem kell tovább konfigurálni, hanem egyből érzékeli a mellé adott gcc-t.Biztosan jó volt a telepítésed?
Egybként a CB+GCC kombót nem feltétlenül ajánlanám olyan kezdőnek, aki Excel-be akarta írni a printf() -et.Ha Windows-on programozol akkor a PellesC vagy az MS Visual Studio barátibb környezetet biztosít.
-
alapz@j
tag
válasz
dobragab #5728 üzenetére
Már fentebb is linkelte valaki, de nekem több gondom is van ezzel a cikkel.
Egyrészt hibás nevezéktant használ, mert azt mondja, hogy van az UNICODE kódolás és az UTF8, holott az UTF8 az egy unicode kódolás.
Másrészt nincs olyan, hogy UNICODE kódolás - a cikk - pontos megnevezése nélkül - az UCS2-t mutatja be, illetve az UCS2-UTF8 konverziók egy részét.
Harmadrészt a cikkben szereplő függvények pont nem segítenek a kérdezőnek, mert neki az ASCII-UTF8 konverziókra van szüksége.
-
alapz@j
tag
válasz
llaszlo #5726 üzenetére
Fogsz egy text editor, beleírod, hogy áÁ éÉ ... az összes ékezetes magyar betűt, kimented UTF8 kódolással, megnyitod egy hex editorral és már meg is vannak a bájtsorozataid a karakterekhez. Ha jól emlékszem, az összes magyar ékezetes karakter kódpontja két bájtosra kódolódik UTF8-ban, ez könnyít a munkán. Ezután írsz egy függvényt, ami unsigned char-ként végigmegy a sztringed bájtjain - ha az adott char < 128, akkor hagyományos módon kisbetűsítesz, ha pedig >= 128, akkor a fenti bájtsorozatokat cseréled.
-
alapz@j
tag
válasz
llaszlo #5724 üzenetére
Szerintem ne erőltesd a wchar-t, mert nagyon sötét erdőbe visz. Ha a bemeneti szövegeid sima ASCII kódolásúak, akkor a használt kódtábla szerint cserélgetheted a nagy- és kisbetűk bájtjait. Ha UTF8 kódolásúak, akkor írj egy olyan függvényt, ami nem csak egy bájtot, hanem egy bájtsorozatot cserél: pl. Á - d0 91 / á - d0 b1.
-
alapz@j
tag
Értem, de azért azt tegyük hozzá, hogy az általa említett Javában is gyakran van szintaktikai változás verziók között - ha jól emlékszem, pl. az 1.5-től jött be a
for (String s : stringArray)
forma a korábban használtfor (int i ...) stringArray.get(i)
kiváltására és nem okozott ez törést senki életében. -
alapz@j
tag
-
alapz@j
tag
válasz
dabadab #5623 üzenetére
Na, a babakódom
#include <string.h>
char maganhangzok[] = "aeiouAEIOU";
char betuk[256];
void setup_betuk(void) {
memset(betuk, 0, 256);
size_t len = strlen(maganhangzok);
for (size_t x = 0; x < len; ++x) betuk[maganhangzok[x]] = 1;
}
inline char maganhangzo_e(char x) {
return betuk[x];
} -
alapz@j
tag
A PellesC-vel nem volt gondod? Én akkor szedtem le a gépemről, amikor kiderült, hogy a totál ansi C forrásból készülő Lua.exe-t (a Lua nyelv értelmezője) csak a PellesC-vel fordítva nem működik rendesen, pedig azzal még a barebone Tiny C Compiler (tcc) is megbirkózott...
-
alapz@j
tag
-
alapz@j
tag
Hogy programozhat úgy valaki, hogy nem érti a szöveges és a binary fájl közötti különbséget?
-
alapz@j
tag
válasz
#36268800 #5427 üzenetére
Írj egy one time pad alkalmazást. Egy hex és base64 kódolót/dekódolót. Aztán valami egyszerűbb ciphert (pl. rot13) használó kis programot. Aztán írj egy programot, amiben egy külső titkosító könyvtár (wincrypto, libnettle, openssl, akármi) egyszerű szimmetrikus titkosítását használod (xxtea, aes, chacha, stb.). Közben ismerkedj meg a secure random, a kriptográfiai hash, a keyed hash fogalmával és használatával. Ezután jöhet az authenticated titkosítás, a nyilvános kulcsú kriptográfia és a többi finomság. És mindeközben sajátítsd el azt, hogyan lehet biztonságos C programot írni, amelyik nem szivárogtat ki információkat az általa kezelt adatokról.
-
alapz@j
tag
Banális kérdés, de valahogy nem egyértelmű számomra: a wide char-okból álló string lezárója a 0x0000?
-
alapz@j
tag
válasz
DrojDtroll #5042 üzenetére
Valaki kijavít, ha tévednék, de szerintem sima getch() (már) nincs. Van a conio.h-s _getch() és van a stdio.h-s getchar().
-
alapz@j
tag
válasz
DrojDtroll #5040 üzenetére
Nem befolyásol semmit, ez a függvény neve:
#include <conio.h>
int _getch( void );
wint_t _getwch( void ); -
-
alapz@j
tag
Persze szubjektív, de számomra a C éppen az ehhez hasonló okos, elegáns, tömör és hatékony megoldásokat jelenti, aminek része az interfész átgondolt felépítése is. Az e() fgv. éppen azért tud ilyen jól működni, mert az általa visszaadott értékek párhuzamban vannak a megoldás matematikai összefüggéseivel.
Ha Javában írnám, tuti én is meghívnék benne 5 Factory-t, 3 Managert-t és 4 Providert, miközben Hibernate-el pakolnám relációs adatbázisba a közben keletkező objektumok százait
-
alapz@j
tag
Ma reggel eszembe jutott még egy tömörítési lehetőség, de már csak haladóknak
int e(unsigned int a) {
return a == 0 ? 0 : (a % 2) + 1;
} -
-
alapz@j
tag
Ha elfogadsz még egy tanácsot: próbálj meg átláthatóbb forrást írni, mert hosszabb programnál el fogsz veszni a kapcsos zárójelekben
#include<stdio.h>
int e(int a) {
if (a == 0) return 0;
return (a % 2) + 1;
}
int main() {
int a;
printf("Adj meg egy szamot: \n");
scanf("%d", &a);
switch (e(a)) {
case 1:
printf("A szam paros\n");
break;
case 2:
printf("A szam paratlan\n");
break;
case 0:
printf("A szam nulla\n");
break;
}
return 0;
} -
alapz@j
tag
válasz
DrojDtroll #4996 üzenetére
Jól megbonyolítottad a dupla tömbökkel
char string[] ="1 22 333 444 5555";
char *pch = strtok(string," ");
while (pch != NULL) {
printf("%i\n", atoi(pch));
pch = strtok(NULL, " ");
}vagy ha már belelendültem:
char *string = "1 22 333 4444 5555";
size_t i = strlen(string);
while (--i) if (string[i] == ' ') printf("%i\n", atoi(string + i));ez utóbbi jobb is, mert a strtok-al ellentétben nem módosítja a stringedet.
-
alapz@j
tag
válasz
DrojDtroll #4988 üzenetére
char *string = "2 31 457";
int i1, i2, i3;
sscanf(string, "%d %d %d", &i1, &i2, &i3); -
alapz@j
tag
válasz
lotuska #4973 üzenetére
Már megbocsáss, de te nem a problémát oldottad meg, hanem a compilert sikerült rávenned arra, hogy szemet hunyjon a hibád felett. Mi akadálya volt annak, hogy a szájbarágós magyarázatnak megfelelően a scanf_s függvényt használd a scanf helyett? És akkor egy csapásra egy buffer overflow lehetőséget is kiküszöböltél volna...
char c;
scanf_s("%c", &c, 1); -
alapz@j
tag
válasz
BTminishop #4956 üzenetére
C-ben is könnyedén lehet GUI-t programozni, akár közvetlenül a Win32 API-t akár valamelyik multiplatform toolkitet, mint a GTK vagy az egyébként általam is használt és imádott IUP. Ettől függetlenül én is a Java Swinget vagy a .Net-et ajánlanám kezdő programozónak, mert azok eleve adottak a Java és a .Net környezetekben, nem kell dll-ekkel vagy statikus programkönyvtárakkal bajlódni.
A kérdésedre egyébként az a válasz, hogy az ablakot a megfelelő függvényhívásokkal hozod létre (kovácsolod a programodhoz): pl. win32 API-val
...
int mydialog = DialogBox(hInstance, MAKEINTRESOURCE(DLG_MYDLG), NULL, (DLGPROC)MyDlgProc);IUP-al:
Ihandle *dlg;
...
IupShow(dlg);stb., stb.
Ja, és egy jó tanács: ne keverjétek a C-t és a C++ -t, még nevükben sem
-
alapz@j
tag
válasz
BTminishop #4953 üzenetére
Nem egészen értem a problémát: ha a Visual Studio-ban (legalábbis gondolom, hogy ez, a sablon-név alapján) a "WindowsFormsApplication" varázsló kitett neked egy ablakot, amit saját ízlésed szerint testre tudtál szabni, akkor lényegében "írtál" egy GUI-val rendelkező programot, nem? Build solution aztán run.
-
alapz@j
tag
A NotePad++ és a Cygwin alapján feltételezem, hogy Windows OS alatt programozol - ebben az esetben a legújabb Microsoft Visual C Express-t vagy a PellesC-t ajánlanám, mindkettő ingyenes és nagyon jó fejlesztői közeg, ez utóbbi teljesen C11 konform és a resource editor is teljes benne (pl. van dialog builder, ami az msvce-ből pl. hiányzik).
-
alapz@j
tag
válasz
#68216320 #4915 üzenetére
Viszont végre jól működik a program, mert az 'á' megjelent - még ha helytelen kódolással is - a feldolgozott sztringben
Egyébként ebből is látszik, hogy ez inkább konzol (terminál) probléma, mert a default 852 kódlappal ugyanaz az exe nálam is megeszi a szó eleji á-t.
-
alapz@j
tag
válasz
Ereshkigal #4901 üzenetére
-
alapz@j
tag
Szerintetek mi az oka annak, hogy a string.h függvényei char* paramétereket fogadnak és char* értékeket adnak vissza unsigned char* helyett, ami - szerintem - a logikus lenne?
-
alapz@j
tag
Na, megint jövök a kérdéseimmel
Csinálgatok most egy kis programot, amihez több, külső forrásból való kódot használok fel. Olvasgattam a hozzájuk tartozó header fájlokat, és feltűnt, hogy olyan definíciók vannak a fájlok elején, hogy
(aes.h)
#ifndef AES_H
#define AES_H
...
#endif(sha256.h)
#ifndef SHA256_H
#define SHA256_H
...
#endifstb. Ezeknek pontosan mi a célja és értelme?
-
alapz@j
tag
A Stack Overflow-n egy ilyen C forrást láttam:
int main() {
@valami {
int x...
}
}A @valami micsoda? Soha nem találkoztam még ilyennel korábban.
-
alapz@j
tag
-
alapz@j
tag
Egy érdekes problémába botlottam, ami három különböző fordítóval is előjön, szóval a kódban lehet a hiba, de nem tudom, hogy mi.
#include <stdio.h>
int main(void) {
char date[] = "2014/05/01";
int year, mon, day;
int res = sscanf(date, "%i/%i/%i", &year, &mon, &day);
printf("%i\n", res);
return 0;
}Ez így jól működik, a res-be három kerül, mert három értéket sikerült beolvasnia a sscanf-nak. De ha a hónapot átírom 08 vagy 09-re akkor azt már nem ismeri fel. Minden más értékre működik. Ha sima 8-at vagy 9-et írok, megint működik. Szerintetek?
-
alapz@j
tag
válasz
buherton #4707 üzenetére
Van egy string könyvtáram, ahol a String típus egy struktúra, amiben egy char* változó mutat a tényleges karaktersorozatra. Hogy a felhasználónak ne kelljen még plusz a memóriakezeléssel is bajlódnia, a sztringek mutable-ként működnek, úgy, hogy a függvények új memóriaterületet allokálnak az eredménynek, a régi területet pedig felszabadítják free-vel Ez ugye a felhasználó számára nem látszik, mert ő mindig ugyanazt a String változót látja. A konstruktor függvény első verziója egyszerűen felvette a felhasználó által megadott char* értéket. Ez viszont nem jó, mert ha a stack-en van a karaktersorozat (és nem static), akkor ugye az megsemmisül, ha char* x = "x" formában definiált volt, akkor az r/o memóriaterületen van és az első free-nél kiakad a rendszer, stb. Úgyhogy a jelenlegi konstruktor duplikálja a karaktersort a heap-re, ami csak annyiban rossz, hogy ha már eredetileg is ott volt, akkor kétszer annyi memóriát használ a program. Az lenne a legelegánsabb megoldás, ha a konstruktor érzékelné, hogy a paraméter a stack-re, r/o területre vagy a heap-re mutat és ennek megfelelő memóriafoglalási stratégiát választana.
-
alapz@j
tag
Van arra mód, hogy egy függvény a paraméterként kapott char* pointerről eldöntse, hogy az read-only, read-write memóriaterületre vagy a heap-re mutat?
-
alapz@j
tag
-
alapz@j
tag
-
alapz@j
tag
Fél szemmel figyelemmel követem az OpenBSD-s srácok OpenSSL újraíró projektjét (LibreSSL) és annak kommentárjait a Opensslrampage.org -on. Az egyik legutóbbi gyöngyszemük az OpenSSL kódból:
strncpy(dest, src, strlen(src))
Ez azért komoly kérdéseket vet fel a kód minőségét illetően...
-
alapz@j
tag
És ha már erre jártam: a napokban kijött a PellesC 8.0 RC2, azaz közel a végleges. Szerintem az egyik legjobb C compiler és IDE, érdemes kipróbálni: KATT
-
alapz@j
tag
válasz
don_peter #4560 üzenetére
A "Valaminev#60#120#185#225#240#260" -ből egy ciklussal a kettőskereszteket nullára cseréled:
Valaminev\060\0120\0185\0225\0240\0260
így létrejön 7 stringed. A char memtomb[7][46] helyett egy pointer tömböt csinálsz (char *memtomb[7]) és menet közben mindig feljegyzed az aktuális stringedre mutató pointert:
unsigned char meminput[] = "Valaminev#60#120#185#225#240#260";
unsigned char *memtomb[7];
memtomb[0] = meminput;
size_t len = strlen(meminput);
int memptr = 1;
for (int i = 0; i < len; ++i) {
if (meminput[i] == '#') {
meminput[i] = 0;
memtomb[memptr++] = meminput + i + 1;
}
}
for (int i = 0; i < 7; ++i)
printf("%s\n", memtomb[i]); -
alapz@j
tag
válasz
Ereshkigal #4551 üzenetére
A Random.org atmoszférikus zajból készít véletlenszámokat, amelyek publikus API-n keresztül elérhetőek. Ez a link pl.
http://www.random.org/cgi-bin/randbyte?nbytes=16&format=h
128 bit valódi random számot ad hexában (az url paraméterek magukért beszélnek).
-
alapz@j
tag
-
alapz@j
tag
Esküszöm nem keresem a c vs. java példákat, de most megint belefutottam egybe: http://raspberrycompote.blogspot.ie/2014/03/programming-language-micro-benchmark.html
A platform RasPi (arm), a feladat prímkeresés. -
alapz@j
tag
A korábbi c vs. java témához engedjetek meg egy linket még: https://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster-than-an-unsorted-array/11227902#11227902
Különös figyelemmel erre e részre: Intel Compiler 11 does something miraculous. It interchanges the two loops, thereby hoisting the unpredictable branch to the outer loop. So not only is it immune the mispredictions, it is also twice as fast as whatever VC++ and GCC can generate! In other words, ICC took advantage of the test-loop to defeat the benchmark... Szóval a konkrét gépi kódtól függetlenül is lehet jelentős sebességnövekedést elérni az adatok ügyes szervezésével.
Érdemes még a további kommenteket is elolvasni, pl. hogy a ternary operator-t mennyivel jobban fordítja a gcc, mint a sima if-then feltételes elágazást.
-
alapz@j
tag
válasz
buherton #4441 üzenetére
> Hogy a fenébe van ideje futás közben újra fordítani?
Nem tudom, de azt csinálja és láthatóan jó eredménnyel. Egyébként abban is sok igazság van, amit te írtál. Hiába dolgoz fel egy százmilliós tömböt gyorsabban a Java-ban írt program, mint a C-ben írt, a felhasználók jelentős részének - teljesen természetes módon - az marad majd meg a Java programból, hogy lassan indul el, nem reszponzív a gui, idegenek a swing komponensek, stb.
> Honnan tudja futás közben, hogy hogyan lehet optimalizáltabb?
Erre van utalás a linkelt cikkben, igaz, nem a Java, hanem a CPU-k kapcsán. El tudom képzelni, hogy a VM a byte kód elemzésekor csinál valamilyen branch prediction-t vagy mondjuk előre lefordít mindkét lehetőségre egy natív kódrészeletet, amivel kiküszöböli a lokális ugrásokat.
-
alapz@j
tag
A java vs. c témakörhöz egy kis nem-annyira-offtopic szösszenet:
http://tifyty.wordpress.com/2012/07/15/es-a-jit-optimalizal-de-meg-mennyire/ -
alapz@j
tag
válasz
buherton #4416 üzenetére
A Minecraft teljesen alap Java-OpenGL bridge-t használ, azaz a megjelenítést a hardver végzi, ha simán portolnák C/C++-ra, nem gyorsulna érdemben - az értékelhető gyorsuláshoz az egész engine-t újra kellene írni. Hozzáteszem, igen régi gép kell már ahhoz, hogy a Minecraft gondban legyen, utoljára talán a csajom core2duo+intel hd kombós gépén láttam szaggatni...
-
alapz@j
tag
válasz
buherton #4409 üzenetére
Ööö, ööö. A Java nem feltétlenül lassú és nem is foglal feltétlenül sok memóriát. 2000-ben ez így volt, ma már nincs - és az Oracle-höz sem vagy kötve mert van még egy tucatnyi másik implementáció. Az oracle-ös HotSpot csak a reference. A C++ platformfüggetlensége pedig megint csak kérdőjeles, mert a cout << "Hello World" tuti működik minden rendszeren, de ha elkezded benne meghívni az OS API függvényeit (mert egy natív GUI-t építesz), akkor máris ugrott a függetlenség.
-
alapz@j
tag
válasz
bucsupeti #4297 üzenetére
A konklúzióval egyetértek, de a folyamattal nem. Egy programozást, mint hobbit megtanulni vágyó embernek soha nem kezdeném azzal az oktatását, hogy na, van a compiler, ami az "elso_valtozom = 0" programsorodat valami olyasmivé alakítja majd át, hogy "mov [elso_valtozom], 0", csak éppen binárisban, de előtt még írjál köré olyanokat, hogy "int main()" és "return 0".
-
alapz@j
tag
válasz
bucsupeti #4295 üzenetére
Programozást nulláról tanulni szerintem az interpretált nyelvek a legjobbak, mert nem kell a fordítás nyűgjével és az esetleges hibák komolyabb következményivel foglalkozni: Python, Perl, Ruby, Lua, bár ez utóbbi kettő nem feltétlenül jó kezdőnyelv. Esetleg JavaScript és akkor egyből GUI is van
Ha az alapok megvannak, akkor lehet abban gondolkodni, hogy a kitűzött célhoz melyik nyelv illene e legjobban.
-
alapz@j
tag
Én mindig ugyanabba a sorba rakom a nyitó kapcsost, még függvény definíciónál is
int main(void) {
return 0;
}a típusjelölésre teszem a csillagot, mert olvashatóbb
char* nothing(char* string) {
return string;
}Ja, és egy sorra soha nem használok kapcsost:
if (..)
for (...)
printf("Hit me!\n"); -
-
alapz@j
tag
válasz
Jester01 #4166 üzenetére
Huh, nagyon jó ez a GCC Explorer, meg is adta a választ:
int main() {
for (int i = 0; i < 5; ++i) {
int x = i + 10;
}
}g++ 4.8 (-O és más kapcsolók nélkül)
main:
push rbp
mov rbp, rsp
mov DWORD PTR [rbp-8], 0
jmp .L2
.L3:
mov eax, DWORD PTR [rbp-8]
add eax, 10
mov DWORD PTR [rbp-4], eax
add DWORD PTR [rbp-8], 1
.L2:
cmp DWORD PTR [rbp-8], 4
jle .L3
mov eax, 0
pop rbp
retÉrdekes, ha jól olvasom, akkor a teljes stack allokálás (int i és int x is) megtörténik már a ciklus előtt, azaz nincs sem menet közbeni allokálás, sem blokk utáni deallokálás.
-
alapz@j
tag
Egy C99
for (..) {
int x = ...
}ciklusban az x minden iterációnál létrejön/megsemmisül a stack-en vagy csak egyszer és mindig az kerül felhasználásra?
-
alapz@j
tag
Esetleg bővebben is ki tudnád fejteni a jelenséget? Milyen program, milyen hibaüzenetet ad, stb?
Ú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!
- Eladó konfig! Ryzen 7 7800X3D 2TB SSD 64GB DDR5 RX9070XT 16GB!
- Új, makulátlan állapotú Samsung Galaxy Buds FE, fehér, fél év garancia
- Új, makulátlan állapotú Samsung Galaxy Watch7 44mm ezüst, 2 év garancia
- Új, makulátlan állapotú Samsung Z Fold 6 256GB Tengerészkék, független, 2 év garancia
- Használt TP-Link Deco M4 - AC1200 Router (Mesh-ként is használható)
- Lenovo ThinkPad X1 Carbon G8, i7-10510U, 16GB, 1TB SSD, 4K kijelző + WWAN (ELKELT)
- Samsung Galaxy S25 Ultra 1TB, Kártyafüggetlen, 1 Év Garanciával
- Gyors, Precíz, Megbízható TELEFONSZERVIZ, amire számíthatsz! Akár 1 órán belül
- Samsung Galaxy S24 Ultra 5G 256GB, Kártyafüggetlen, 1 Év Garanciával
- ÁRGARANCIA! Épített KomPhone i5 12400F 16/32/64GB RAM RTX 3060 12GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest