- ASUS ROG Ally
- Kormányok / autós szimulátorok topicja
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Hogy is néznek ki a gépeink?
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Amlogic S905, S912 processzoros készülékek
- Alapértelmezett konfiguráción sok Core CPU-nak lehet stabilitási gondja
- Házimozi haladó szinten
- OLED TV topic
- ThinkPad (NEM IdeaPad)
Hirdetés
-
Kiadta a CopprLink specifikációját a PCI-SIG
ph A PCI Express 5.0-s és 6.0-s szabványhoz készülő belső és külső összeköttetés az adatközpontokban találhat otthonra.
-
Egyre közelebb a Poco F6 startja
ma Újabb ár/érték csatát nyerhet a Xiaomi almárka.
-
A franciáknak elege van abból, hogy minden gyerek mobilozik
it Vissza akarják szorítani a gyerekek és tinédzserek közösségi média- és okostelefon-használatát.
Új hozzászólás Aktív témák
-
jattila48
aktív tag
válasz EQMontoya #3200 üzenetére
Majd kipróbálom. De hogy ezt meg tudja oldani, ahhoz a TU-kon "átlátó" optimalizáció kéne. Ezt tudja a g++? Én azt hittem, hogy az optimalizáció csak TU-n belül működik. Mivel itt a BodyClass esetleges ősosztályaitól függ, hogy hogy optimalizálható a kód, ezért ezt az információt meg kell tartani az object fájlban is, ha TU-k közötti optimalizációban szeretnénk ezt elvégezni. Esetleg pszeudokódot generáló fordítóknál lehetséges ez. Nem tudom, hogy a gcc végez-e ilyen pszeudo kód generálást majd azon optimalizálást, lehetséges. De akkor talán inkább az LLVM. Minden esetre a kérdés érdekes.
[ Szerkesztve ]
„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 EQMontoya #3202 üzenetére
Kipróbáltam, és nem tudja kioptimalizálni a thunk kódot. Viszont lehet, hogy a gcc-ben is van __single_inheritance-nek megfelelő kulcsszó. Erről mit lehet tudni?
„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
Heti fun. Nem én írtam, úgy küldték még régebben, szerintem zseniális.
template <typename... ARGS>
void print_stuff (ARGS const &... args)
{
using swallow = int[];
(void) swallow {0, ( (std::cout << args), 0)...};
}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 #3207 üzenetére
Hát, szintaktikusan biztos hogy hibás. using stílusú typedef-et soha nem használtam (VS2012 le sem fordítja), de nem is értem mit kéne csinálnia. Mi a (void) a swallow előtt? Gondolom különböző típusú argumentumokat írna ki. Kerek zárójelek nincsenek párban, a végén a ... sincs jó helyen (szerintem), szóval ennyi.
[ Szerkesztve ]
„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 #3208 üzenetére
Fordítsd normális fordítóval, ami támogatja a C++11-et, a zárójelek is rendben vannak. Pl. MinGW-GCC 4.8+
Létrehoz egy int-ekből álló tömböt, amit nullákkal tölt fel, és feltöltés közben egyesével kiírja az argumentumokat. Majd ezt a tömböt eldobja, mert nekünk csak a kiírás kellett, a (void) a compiler warning miatt kell.
Tudtommal ez a legegyszerűbb implementációja a variadic template-es mindent kiíró függvénynek, általában két függvény kell hozzá.
Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.
-
ToMmY_hun
senior tag
Láma kérdés következik: Van egy Parent és sok Child osztályom. Az ősosztályban van egy paraméter, legyen a neve ID. Ezt az ID-t muszáj setelnie minden leszármazottnak, azonban tudomásom szerint nincs mód arra, hogy a default constructor helyett egy paraméterezettet hívjon meg az ősosztályban a leszármazott osztály konstruktora. Szóval szerintetek az mennyire jó megoldás, ha az ősben csinálok egy setparameters metódust és ezt hívom meg a leszármazott konstruktorában? Természetesen ha az ID nem megfelelő, akkor dob egy illegal_argument exception-t, így nem történik meg a példányosodás az alosztályból. Arra természetesen figyelek, hogy az ősosztályból létrejött példány is destruáljon.
C programmers never die, they are just cast into void.
-
dobragab
addikt
válasz ToMmY_hun #3210 üzenetére
Van mód arra, hogy ne a default-ot hívja meg a leszármazott, mégpedig inicializáló listán. A "setter" ctort akár protected-be is teheted.
class Parent
{
int id;
protected:
Parent(int id) :
id(id)
{ }
public:
Parent() {}
};
class Child : public Parent
{
public:
Child() :
Parent(0)
{ }
};[ 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 EQMontoya #3213 üzenetére
Irodalomként ez megfelelő? cppreference
Ezt olvastam el és ez alapján írtam meg. Bár eléggé tömör, szóval a lényeget nehéz volt kibogarászni belőle.C programmers never die, they are just cast into void.
-
r4z
nagyúr
Nagyon láma kérdés következik.
Adott egy A és egy B osztály. A-nak az egyik adattagja B. Egy B többszáz A-hoz is tartozhat, és minden A-hoz tartoznia kell pontosan egy B-nek. Mindkettőt külön, rendszerezve szeretném tárolni/módosítani/törölni.
Hogyan érdemes nekiesni az adatszerkezetnek? Mindkettőből lista, és A B-nek csak a pointerét tartalmazza, vagy van ennél jobb megoldás is?
I don't love people. I love 911s, Astral Projection and french fries, in that order.
-
EQMontoya
veterán
Akkor gyorsan olvass utána a smart pointereknek. Úgy alapból a koncepciónak, hogy miről is szól ez az egész, utána pedig:
-kezdetben vala az auto_ptr
-majd lőn helyette unique_ptr
-kicsit bonyolultabb helyzetekre pedig van shared_ptr és weak_ptr (mint pl. a lentebbi, amikor több "tulajdonosa" van egy objektumnak)Same rules apply!
-
ToMmY_hun
senior tag
Sziasztok!
Ismét lenne egy kezdő kérdésem. Van néhány egymáshoz nagyon hasonló osztályom, amelyek különböző típusú objektumokat tárolnak. Szeretném megoldani azt, hogy minden ilyen osztály rendelkezzen előre deklarált metódusokkal, amelyek osztályonként különböző típusú objektummal térnek vissza vagy végeznek rajtuk műveletet. Az megfelelő megoldás, ha csinálok egy template osztályt és az abból készült osztályból származtatok le a konkrét, felhasználásra szánt osztályokban? Amennyiben nem, akkor mi a szebb megoldás?
Köszönöm előre is!
[ Szerkesztve ]
C programmers never die, they are just cast into void.
-
jattila48
aktív tag
válasz ToMmY_hun #3221 üzenetére
Lehet, hogy nekem nehéz a felfogásom, de a magam részéről nem értem mit szeretnél.
"Van néhány egymáshoz nagyon hasonló osztályom, amelyek különböző típusú objektumokat tárolnak."
Tehát ezek az osztályok konténerek? Egy konténeren belül lehet egymáshoz képest különböző típusú objektumokat tárolni, vagy egy konténer egy adott típusú objektumok tárolására alkalmas?
"minden ilyen osztály rendelkezzen előre deklarált metódusokkal, amelyek osztályonként különböző típusú objektummal térnek vissza vagy végeznek rajtuk műveletet"
Mármint az adott metódust (c++ -ban tagfüggvény) tartalmazó osztályonként..., vagy paraméterben kapott objektum típusától függően térnek vissza...?
Ha konténerről van szó, akkor ezt mint template-et akarod a tartalmazott objektumok típusával paraméterezni? Miért akarsz leszármaztatni? A leszármazott osztály valamely objektumára mutató pointert (referenciát) ősosztály típusúként akarod használni?
Egy kicsit konkrétabban, és részletesebben írd le mit szeretnél, akkor talán tudunk segíteni.
[ Szerkesztve ]
„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 #3222 üzenetére
Először is köszi a választ! Konkretizálom a kérdést. Konténereket szeretnék csinálni, de mindegyik konténerben különböző típusú objektumot akarok tárolni. Szeretnék egy ősosztályt ezeknek a konténereknek, amelyben megadom a kötelezően megvalósítandó tagfüggvényeket, egyelőre két darabot. Egyik új elemet helyez bele, a másik pedig elkéri az elemet azonosító alapján. Az ötletem az lenne, hogy készítek egy template osztályt, amiben definiálom a put és get tagfüggvények működését, mivel a konténereknél csak típusbeli különbség van, ezen felül működésbeli nincs. Azért szeretném így megoldani, mert így viszonylag jól rétegezett és utólag könnyen bővíthető lenne a kód - legalábbis szerintem. Tehát ezek tükrében jó ötlet a template, vagy más felé tapogatózzak?
C programmers never die, they are just cast into void.
-
dobragab
addikt
válasz ToMmY_hun #3223 üzenetére
Jó irányba tapogatózol, a template a megoldás. Amit te keresel, az az std::vector. Mindent tud, ami neked valaha kelleni fog dinamikus tömb szintjén. Egyrészt tud automatikusan megnyúlni (push_back), viszont előre is le tudja foglalni a memóriát, és nem kell nyújtózkodnia, ha konstruktorparaméterként adod neki a darabszámot, vagy reserve-ölsz. Természetesen ezután is tud megnyúlni.
Túl jávásan gondolkozol. Egyrészt teljesen felesleges nekik ősosztály, anélkül is lehet különböző típusokat megetetni egy generikus algoritmussal: erre való a template. Másrészt a get helyett C++-ban illik indexelő operátort használni.
std::vector<int> vec(100); // 100 darab helyet lefoglal előre,
// de nem tölti fel, egy darab int sem kerül bele
vec.push_back(1); // belekerült az első elem
for(int i = 0; i < vec.size(); ++i)
std::cout << vec[i];Egy generikus algoritmus lényege a duck typing: minden, ami úszik, és hápog, az kacsa. Másképp: az alábbi algoritmus bármilyen típust tartalmazó vector-ral működni tud, aminek van rendes (std::ostream-et visszaadó) << operátora. Ha te ezt meghívod std::vector<int>-ekre, akkor a fordító fordítási időben legenerálja neked a print<int>-et, mert az int úszik és hápog (van << operátora).
template<typename T>
void print(std::vector<T> const& vec)
{
std::cout << vec(i) << ' ';
}[ 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 dobragab #3224 üzenetére
Köszi szépen a részletes leírást! Jól sejted, valóban Javaztam eddig. Azt nem hangsúyoztam ki a kérdésemben, hogy kulcs-érték párokat szeretnék tárolni a könnyű visszakereshetőség miatt, szóval vector helyettt inkább map-et használok majd. Szükség lesz egy STL tárolót burkoló osztályra, mert szeretném megoldani hogy az összes konténerben egy kulcs csak egyetlen egyszer szerepelhessen, biztonsági okokból.
"...std:: ostream-et visszaadó) << operátora..."
Ezt manuálisan overloadolnom kell saját osztály esetén?
Más kérdés: Hamarosan aktuális lesz az álláskeresés, és ennek okán kérdezném, hogy szerintetek mi az, amivel mindenképpen tisztában kell lennie egy juniornak C++ kapcsán?
Köszi előre is!
[ Szerkesztve ]
C programmers never die, they are just cast into void.
-
jattila48
aktív tag
válasz ToMmY_hun #3225 üzenetére
"Szükség lesz egy STL tárolót burkoló osztályra, mert szeretném megoldani hogy az összes konténerben egy kulcs csak egyetlen egyszer szerepelhessen, biztonsági okokból"
Ez miért, és hogyan? Amikor kiválasztod, hogy melyik tároló objektum milyen kulcsú elemét használod, az már egyértelműen azonosítja a kiválasztott elemet az összes konténer tekintetében. Miért kéne, hogy két különböző konténer objektumban ne lehessen azonos kulcsú elem (ha jól értem, ezt szeretnéd elérni)? Lehet, hogy "véletlenül" más tárolót jelölsz ki, mint amit akartál? Nem értem.
"Ezt manuálisan overloadolnom kell saját osztály esetén?"
Nem overloadolni, hanem megvalósítani.
„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 #3227 üzenetére
Megint nem írtam le a teljes problémakört. Szóval ez az ID azonosítani fogja egyértelműen az objektumot ebben a programban, és egy socketen keresztül csatlakozott programban a hozzá tartozó, ID alapján meghívandó szkripteket. Ahhoz, hogy ne legyen kavarodás abból, hogy egy ID többször szerepel, ezt már itt lekezelem, így könnyebb lesz a dolgom a későbbiekben. Logikailag is inkább ide tartozik, mint egy felsőbb rétegbe.
"Nem overloadolni, hanem megvalósítani."Ezt miért nem overloadnak nevezik? Ismereteim szerint egy már létező operátor új típusokkal való műveletvégézésnek definiálása az overload, ezek szerint rosszul tudom?[ Szerkesztve ]
C programmers never die, they are just cast into void.
-
dobragab
addikt
válasz jattila48 #3226 üzenetére
Valóban.
template<typename T>
void print(std::vector<T> const& vec)
{
for(int i = 0; i < vec.size(); ++i)
std::cout << vec[i] << ' ';
}És igen, minden saját osztályra, amit ki szeretnél írni, érdemes overload-olni az operator<<-t.
std::ostream& operator<<(std::ostream& os, Ratio r) // tört osztályra
{
os << r.get_num() << '/' << r.get_den();
return os;
}[ 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 dobragab #3230 üzenetére
Rendben, köszönöm szépen! Készen is van és működik frankón Közben ismét új kérdés merült fel. Szeretnék logolni fájlba, Java-ban a log4j-t használom erre nagy általánosságban. Azt tudom, hogy C++ támogatás is van benne, de esetleg ismertek jobb megoldást?
C programmers never die, they are just cast into void.
-
jattila48
aktív tag
válasz ToMmY_hun #3229 üzenetére
És ezt az ID-et miért nem az adott konténer példány azonosítójából, és az elem kulcsából generálod (tulajdonképpen (konténer_ID,elem_kulcs) pár valamilyen kódolásban)? Ez egyértelműen azonosítaná az adott elemet, és nem kéne, hogy a kulcs az összes konténerre vonatkozóan egyedi legyen. Ezt a generált ID-et küldhetnéd aztán át a hálózaton, hogy kiválaszd a megfelelő szkriptet. Nem tudom, jól értettem-e.
„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 #3234 üzenetére
Jól érted, és valóban az általad írt is jó megoldás. Amennyiben sok elemem lenne a map-ekben, akkor az általad javasoltat alkalmaznám, mert kisebb az erőforrásigénye a beillesztésnek. Az enyémben ugye ellenőrizni kell, hogy rendelkezésre áll-e az ID, és ez a lista egy sima vector-ban van tárolva, amiben iterálva keresek. Mivel az a helyzet, hogy a program indításakor nagyjából 20 elem kerül tárolásra a különböző konténerekben, itt nem igazán nyernék sokat az általad javasolt implementációval, legalábbis amennyire én meg tudom ítélni. Nagy elemszám vagy gyakori beillesztés esetén egészen más a helyzet.
Köszi a választ! Amúgy örülök neki hogy belekérdezel/kérdeztek, gondolom ilyesmire kell majd számítani a szakdoga bemutatáson is.
[ Szerkesztve ]
C programmers never die, they are just cast into void.
-
dobragab
addikt
válasz ToMmY_hun #3235 üzenetére
Az enyémben ugye ellenőrizni kell, hogy rendelkezésre áll-e az ID, és ez a lista egy sima vector-ban van tárolva, amiben iterálva keresek.
Gyorsabb lenne a különálló map-ekben keresni, mint egy vector-t lineárisan végignyalni. Ha már mindenáron önálló nyilvántartást vezetsz róluk, arra az std::set való.
Trükkös a map és a set, contains függvényük nincs, illetve van, de count-nak hívják.
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 dobragab #3236 üzenetére
Valóban, köszönöm a tippet, így viszont érvényét veszíti amit az előbb írtam. Nem tudom hogy siklottam át felette, mert eléggé ideális megoldásnak tűnik a set használata. Lecserélem majd, de most vár még egy kellemes este socketezéssel meg multithreadinggel.
C programmers never die, they are just cast into void.
-
dobragab
addikt
válasz dabadab #3238 üzenetére
Szerintem a multimap miatt van így. multimap-nél van értelme a count-nak, mindenképp meg kell írni a count-ot. Mást jelent a contains, felesleges lett volna megírni, mert használhatod helyette a count-ot is minden értelmes kontextusban.
bool asd = mmap.count("idk");
if(mmap.count("idk"))
...Megírhatták volna a contains-t is, de minek? Egyetlen int->bool típuskonverzió miatt? Ha nem akarsz a visszatérési értékkel pl. template osztályt példányosítani, semmi baj vele.
bool contains(Key key)
{
return count(key);
}Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.
-
dabadab
titán
válasz dobragab #3239 üzenetére
"Megírhatták volna a contains-t is, de minek?"
Ergonómia, ahogy mondtam.
Melyik olvashatóbb?if(mmap.count("idk"))
vagy
if(mmap.contains("idk"))
Lefordítva meg mind a kettő ugyanaz, az STL kódolásánál meg dokumentálásánál meg kb. nulla többletmunkát jelentett volna és nagyjából ez lenne a második-harmadik leggyakrabban használt metódus a konténereknél.
DRM is theft
-
jattila48
aktív tag
válasz dabadab #3240 üzenetére
Nem szokás olyan publikus tfv.-t írni, ami már meglévő publikus tfv.-ekkel megvalósítható. Az ilyet nem tfv.-ként kell megírni, hogy növeljék az enkapszulációt. A free fv.-eket kell előnyben részesíteni a tfv.-ekkel, és a friend fv.-ekkel szemben. Talán ez lehet az oka.
[ Szerkesztve ]
„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
Sziasztok!
Ismét lenne egy kérdésem. Eddig Java-n nevelkedtem OOP tekintetben, és nem tudom hogy itt mennyire elfogadottak az ott alkalmazott módszerek. Szeretnék socket-en keresztül kiküldeni struktúrákat, a túloldalon Python szkriptek hallgatóznak. Én úgy csinálnám meg a jelenlegi tudásom szerint, hogy egy JSON Parser library-vel sorosítanám a struktúrát, majd áttolnám socketen és Python-ban visszaalakítanám. Mennyire elfogadható megoldás ez C++ esetén? Esetleg van vamilyen kevésbé erőforrásigényes megoldás? A mostani programnál nem számít annyira az overhead, csak a későbbiekben nem ártana tudni milyen lehetőségek vannak.
C programmers never die, they are just cast into void.
-
Karma
félisten
válasz ToMmY_hun #3243 üzenetére
Miért pont socketek? Mi lesz a socketek állapotgépével, a hibakezeléssel?
Miért törnél arra, hogy újra feltaláld a kereket?Van rengeteg protokoll, amit mások már implementációval együtt kidolgoztak neked.
Ott az MQTT, ami elég karcsú beágyazott rendszereknek is. Az óvilág szabványaiból ott az SNMP. Vagy ott a Protocol Buffers, a Thrift és az Avro, amikkel hatékonyabb és strukturált kommunikációt írhatsz. De ha az overhead nem számít, Pythonban egy sorral tudsz HTTP szervert írni, amit a másik oldalad egyébként bejáratott eszközökkel és egyszerűen hívogathat...Ebben semmi C++ specifikus nincs, nem véletlenül tettem OFF-ba a hozzászólásom. A megközelítésed a Java világban is öngyilkosság.
[ Szerkesztve ]
“All nothings are not equal.”
-
ToMmY_hun
senior tag
Az a helyzet, hogy van egy program amivel kommunikálnom kell. Konkrétan Blenderről van szó, ő pedig Python szkripteket futtat. (azt is elég bénán) Nem egészen arra van kitalálva, amire én használni szeretném, de hosszabb keresgélés után sem találtam alkalmasabb programot, ami ingyenes és cross platform. Szóval adott a Blender és adott a C++ kódom, őket kell kommunikációra bírni. A socketezésre ZeroMQ-t használtam eddig, azzal ment (megy) is minden. A belső állapotoknak az üzenetektől függően kelleni fog állapotgép, viszont magát a socket üzenetkezelést természetesen valamilyen library-re bízom (ez esetben ZeroMQ), miért is tennék másképp. Így is rossznak látod a megközelítési módot? Számomra annyira nem érződik a nehézsége vagy a kerék újra feltalálása, persze lehet, hogy rosszul érzem.
[ Szerkesztve ]
C programmers never die, they are just cast into void.
-
Karma
félisten
-
jattila48
aktív tag
válasz ToMmY_hun #3247 üzenetére
Hát, én nem tudom, mi az a ZeroMQ, thrift, meg avro (őszintén szólva nem is nagyon érdekel), de könnyen lehet, hogy a te problémádra ez az ágyúval lövöldözés verébre esete. Nem kell megijedni a TCP socket-ektől, semmilyen külön library nem kell hozzá, simán a BSD (POSIX) socket API-t kell használni, nem bonyolult. Az átküldendő objektumot persze előbb szerializálni kell. Ezt magad is megteheted, azért általában ez sem annyira bonyolult. C++-ban (tudtommal) nincs külön könyvtár a szerializálásra, ezért ha esetleg nem magad csinálod, akkor a google protocol buffer jó lehet. Ez C++ kódot generál, amit a programodba beépíthetsz. Python oldalon nem tudom, hogy van-e protocol buffer. Sajnos nem túl egyszerű telepíteni, és a generált kód sem túl optimális, ezért én a helyedben saját megoldással próbálkoznék.
Az SNMP nem tudom, hogy merült fel, szerintem az tök másra való.„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 #3248 üzenetére
BSD API szerintem önmagad tökönszúrása, annyi platformfüggetlen, egyszerűen használható lib van. Annál még az SDL_net is jobb Pláne, ha vindózra is gondolni kell.
Jól néz ki ez a ZeroMQ, nem ismertem
Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.
-
dabadab
titán
válasz jattila48 #3248 üzenetére
"Nem kell megijedni a TCP socket-ektől, semmilyen külön library nem kell hozzá, simán a BSD (POSIX) socket API-t kell használni, nem bonyolult."
Az API nem bonyolult.
Amíg megcsinálod azt, hogy azt használva legyen egy megbízható, normálisan és jól működő kommunikációs layered, az viszont igen.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!
- Politika
- Poco F5 - pokolian jó ajánlat
- Tőzsde és gazdaság
- Elektromos rásegítésű kerékpárok
- ASUS ROG Ally
- Célkeresztben az OnlyFans, amiért pornót nézhetnek a gyerekek
- Skoda, VW, Audi, Seat topik
- Renault, Dacia topik
- OnePlus Nord 2 5G - észak-északkelet
- Kormányok / autós szimulátorok topicja
- További aktív témák...