Új hozzászólás Aktív témák
-
mgoogyi
senior tag
válasz
jattila48
#3599
üzenetére
Vektorban ismétléseket keresni nem annyira hatékony. Vagy arra alapozol, hogy úgyis alacsony lesz az elemszám egy adott scope-ra?
Alapból nem tűnik jó ötletnek vektorba berakni egy csomó castolni való cuccot.Valszeg többet kellene tudnunk, hogy érdemben hozzá tudjunk szólni a témához.
Jó lenne tudni, hogy mikor mire használod a vektort, mikor van beszúrás, keresés, törlés, stb.
Az objektumok feldolgozása soros módon történik? Teszem azt be lehet rakni mindezt egy process nevű virtuális függvénybe, ami specifikus minden altípusra? -
jattila48
aktív tag
válasz
dobragab
#3597
üzenetére
Hát akkor marad a típus vizsgálat, static_cast. Nem tudok jobbat. A típusvizsgálatot virtuális fv. használatakor sem lehet elkerülni, hiszen a konkrét típus ismeretében tudom csak eldönteni, hogy meghívjam-e egyáltalán a virtuális fv.-t (ami ráadásul a többi osztályban esetleg nincs is implementálva). Ez után a static_cast már csak a fordítót terheli, a futást nem, szemben a virtuális fv. hívással.
A különböző típusok külön táblázatban való tárolása nem opció, mert nagyon megnehezíti a szimbólum hozzáadást, -keresést, scope kezelést, ráadásul ezeket a fv.-eket át kell írni, ha új típusú szimbólumot vezetnék be. Ez egy olyan példa, hogy noha a tárolandó osztályoknak látszólag nem sok közük van egymáshoz, mégis más okból (scope-ban nem lehetnek azonos nevű szimbólumok) célszerű őket együtt tárolni. Szóval szerintem nem tervezési hiba. A külön táblázatok viszont az lenne. -
jattila48
aktív tag
válasz
dobragab
#3597
üzenetére
Ez most egy kicsit bonyolult, de pl. változó esetén a stack-en elfoglalt helyét, az érték típusát, és a statikus level-t tartalmazza. Függvény esetében a fv.-tábla-beli pozíciót, paraméterek számát, típusát, stb. Osztály definíció esetén ...elég bonyolult. A lényeg, hogy teljesen mások a szimbólumok, viszont a scope kezelés miatt egy vektorban (igazából stack-ben) kell őket tárolni.
-
jattila48
aktív tag
válasz
dobragab
#3595
üzenetére
Konkrétan ez egy interpreter szimbólum táblája. Lehet benne változó név, típus név, foglalt kulcsszó, függvény név, stb. A konkrét típustól függetlenül, az adott scope-ban nem lehetnek egyező nevű szimbólumok, akkor sem, ha különböző típusúak. Ezért kell őket egy vektorban tárolni, hogy ezt ellenőrizni lehessen. Még csak neve sincs minden szimbólumnak. A változó pl. teljesen másképp kezelendő, mint a típus definíció. Nem hiszem, hogy ez tervezési hiba lenne.
-
-
jattila48
aktív tag
válasz
dobragab
#3593
üzenetére
Erre gondoltam, de mit adjon vissza a virtuális fv.? A konkrét típusú this pointert (kovariáns típus)? Az nem jó. Más virtuális fv.-t meg nem lehet bevezetni, mert amúgy a típusok teljesen különbözőek. Az egyiken elvégezhető művelet értelmezhetetlen a másikon. Ebben az esetben mit csináljon a virtuális fv,? Exception-t dobjon? Vagy esetleg az ősbeli pure virtual-nak legyen törzse, ami exception-t dob, ha meghívódik? Másrészt az ősosztályban fel kéne venni virtuális fv.-ekként az egyes konkrét osztályokon értelmezhető műveletek unióját. Vagy rosszul értem, amit írtál?
-
jattila48
aktív tag
Egy vektorban szeretnék különböző típusú objektumokat tárolni. Ezt nyilván nem lehet, ezért a tárolandó objektumok osztályai egy közös őstől származnak, ami csak a konkrét leszármazott típusra utaló enum mezőt tartalmaz. Az objektumokat new-val hozom létre, és a pointereket (mint ősre mutató pointer) tárolom el a vektorban. Igazából unique_ptr-eket tárolok, de ez most lényegtelen (std::vector<std::unique_ptr<Base> >). Amikor a vektor egy elemére hivatkozok, akkor az adott unique_ptr-ből nyert raw pointert kapom vissza, amit a típusmezőnek megfelelően futás időben static_cast-olok a konkrét leszármazott típusra. Ezzel az a baj, hogy állandóan vizsgálni kell a típusmezőt, és elvégezni a static_cast-ot. Van-e ennek jobb megoldása? (Boost-ot nem használok, ezt ne is javasoljátok).
-
dobragab
addikt
Szerintem az egysoros fuggvenybe bezsufolt hibak szamat ezzel sikerult maximalizalnia az elkovetonek.
bool static getValue(const MsgType* pMsg, std::string tag, std::string& value)
{
return pMsg->getPair(tag, value);
}Mindezt hasznalja egyetlen helyen:
boost::bind(&getValue, &msg, _1, _2); -
ny.erno
tag
Hogy szakmai, az szinte biztos, de h a programozás melyik nyelvéhez tartozik, ezt nem tudom eldönteni.. Hallotátok/tudok róla?
Mik ezek a robotok és milyen "feladatokat" lehet rájuk bízni?
Mondta a srác is, h nem ő csinálta, ő csak bérli.. Ezt pontosan hogyan kell elképzelni?
/Nem az jutott eszembe, hogy most akkor laikusként bérlek mindenre robot, már ha van ilyen, hanem csak érdekel a dolog, szóval akinek van ideje akár linkelni, akár írni rá magyarázatot, az tök szuper lenne.
/ -
pvt.peter
őstag
Sziasztok,
Arra van vmiféle lehetőség, hogy egy
switchutasításban levő ágakat megszámoljam fordítási időben és ha nem egyenlő egy bizonyos számmal akkor error -t dobjak?
Arról van szó, hogy van egyQMap<int, QString>változóm amelyben <hibakód, hibaüzenet> -eket tárolok.switchutasításban pedig adott egész szám alapján kérek le hibaüzenetet.
A probléma az, hogy ha nincs olyancaseág amely alapján letudna kérniQString-et aQMap-ből akkor nem fog visszaadni semmit sem (defaultág, stb.).Emiatt elsősorban a
caseágak számát szeretném ellenőrizni aQMapméretével. Amennyiben nem egyeznek meg, akkor vmi baki van.Másodsorban a precízebb megoldás az lenne, hogy a
caseágak feltételeit ellenőrizném le, hogy benne vannak-e aQMap-ben kulcsként.Nyilván a fentebbi igényeket el lehet végezni unit tesztekkel is, sőt igazából ezzel kellene.
A kérdésem viszont most fordítási időre vonatkozna és vmi statikus assertes dolgot keresnék erre.
Előre is köszönöm a választ.
-
dobragab
addikt
válasz
jattila48
#3582
üzenetére
Igen, az
static int Eakart lenni.
Ha masra nem, arra mindenkepp jo, hogy a
typenamekulcsszot megtanulod becsulni, sot orulsz neki, hogy csak ennyi helyen kell kirakni, mert legtobbszor ki tudja talalni a fordito.(#3583) kispx
Az elsot tenyleg elcsesztem.
Masodik esetben vigyazz, a
::Eglobal scope. -
-
dobragab
addikt
válasz
jattila48
#3579
üzenetére
Akkor a tobbi megoldas, termeszetesen nem csak a definialt tipusban ternek el, hanem elvi kulonbseg van.
2.
int A, B;
A * B; // eldobjuk a visszateresi erteket
typedef int D;
template<typename T>
struct C
{
int E;
};
int X;
C<D>::E * X;3. Talan ez faj legjobban. Szintaktikailag ez is helyes.
int C, D, E, X;
C<D>::E * X; -
dabadab
titán
A Stroustroup könyvnek meg az Effective C++-nak kb. semmi köze nincs egymáshoz.
Az egyik leírja, hogy mit tud a nyelv, a másik meg egy receptgyűjtemény, hogy mit hogyan érdemes használni és mire kell figyelni (és ez feltételezi azt, hogy az ember azért nagyjából már tudja, hogy mit tud a nyelv).
-
EQMontoya
veterán
válasz
ToMmY_hun
#3567
üzenetére
A "const" csak a változó állandó értékéért felel, míg a "static" azért, hogy csak egy példány jöjjön létre?
Pontosan.
Ha const tagja van, az az jelenti, hogy csak konstruktorban kaphat értéket, de több példánynak lehet különböző értékű ilyen tagja.
Ha static, akkor minden példány ugyanazt az egyet példányt látja az adott tagváltozóból, ami kvázi a program indulásánál kap értéket. -
ToMmY_hun
senior tag
Sziasztok!
Olvasok egy C++ könyvet, és felmerült bennem egy kérdés, amire gyors keresés után nem találtam választ. Az lenne a kérdés, hogy mi a különbség egy tagváltozó "const static" illetve "const" definiálása között. A "const" csak a változó állandó értékéért felel, míg a "static" azért, hogy csak egy példány jöjjön létre?
Köszi előre is!
-
dobragab
addikt
Az az Enforcement priceless.
-
dobragab
addikt
-
dobragab
addikt
Van egy tippem. Ezt írtad:
template<class T, class Comp = std::less<T>>Az utolsó két karakter a C++98 parsing szabályok alapján (mohó algoritmus) egy jobbra shiftelő operátor. Tegyél közé egy szóközt, így:
template<class T, class Comp = std::less<T> >Amúgy ez gyakorlatilag egy hiba a C++98 szabványban, C++11 szerint a felső változat is jó.
Másik hiba: az
std::lessnincs benne sem alist, sem azalgorithmheader-ben,functionalkell hozzá.Szerk: látom, közben megtaláltad.
-
Sziasztok! Hibás ez a kód, mit nem veszek észre?
#ifndef SL__H
#define SL__H
#include <list>
#include <algorithm>
template<class T, class Comp = std::less<T>>
class SortedList{
std::list<T> lt;
public:
int size() const{
return lt.size();
}
void insert(const T& t){
lt.insert(std::lower_bound(lt.begin(),lt.end(),t,Comp()), t);
}
const T& front() const{
return lt.front();
}
};
#endifHibaüzi:
sl.h:7:32: error: expected type-specifier
template<class T, class Comp = std::less<T>>
^
sl.h:7:32: error: expected '>'
sl.h:8:17: error: expected unqualified-id before '{' token
class SortedList{ -
dobragab
addikt
Kaptunk új formázást, a Programkód mostantól így néz ki. Aki a régit akarná használni, Monospace + Konvertálatlan kombóval tudja.
template<typename... ARGS>
void print_all(ARGS&&... args)
{
using swallow = int[];
(void)(int[]){0, ((void)(std::cout << args), 0)...};
}Felismeri a nyelvet magától
-
EQMontoya
veterán
Belsős workshoprul, publikusan:
Arról volt szó, hogy hogyan lehetne okítani a népet, aki már valamennyire tud c++-ul, illetve milyen egységes coding standard-et és hasonlókat lehetne felállítani.
Bjarne nagyon annak a pártján állt, hogy legyen egységes coding guideline, és a Microsoft meg a gnu fordítók is sok checkert be fognak tolni az új dolgokkal kapcsolatban, meg a coding quideline betartásához warningokat, de ez egyrészt még sok idő, másrészt ami ennyire univerzális, az nem szokott túl jól működni.
Szóval nekem úgy tűnt, hogy Ő ilyen békés professzorként szemléli ezt a kérdést, nekünk meg kicsit gyakorlatiasabb hozzáállásra van szükségünk, ezért annyira nem volt produktív a dolog.
Jó arc amúgy az öreg, meg humora is van valamennyi.Abban mondjuk nagyon egyetértettünk, hogy az ilyen self-made manek sokkal többet ártanak, mint használnak: széthackelt, látszólag rommá optimalizált kódot írnak, amivel persze a compiler féle optimalizációkat lehetetlenítik el, és a végeredmény egy olvashatatlanabb kód, ami még lassabb is lesz.
Lásd: az egyik baromarc a cégnél írt saját bitsetet. Komoly munkával összetákolta, majd kicseréltük boost-osra, és 60%-kal gyorsabb lett. -
ToMmY_hun
senior tag
Kicsit off, de talán tekithető közérdekűnek. A minap keresgéltem az App Store-ban és találtam egy alkalmazást, amivel C++ kódot írhatunk és fordíthatunk iOS eszközön. Szerintem nagyon frankó, épp a minap demóztam vele egy ismerősömnek a virtuális függvények működését.
-
dobragab
addikt
Napi mitírki. Aki tudja a választ, ne nagyon lője le. Igazából nem is mitírki, inkább rejtvény.
#include <iostream>
int main()
{
/* declare x here */ ;
std::cout << ((char*)&x - (char*)x); // prints 0
return 0;
}Deklaráld x-et a megjelölt helyen úgy, hogy az alatta lévő sor tényleg 0-t ír ki. Megkötések:
1. nem törölhetsz kódot, csak a megjelölt kommentet "cserélheted ki" valamire
2. nem írhatsz bele pontosvesszőt (a sor végén van egy, csak az elé írhatsz)+1: oldd meg úgy, hogy x-et nem inicializálod.
-
dobragab
addikt
válasz
EQMontoya
#3519
üzenetére
Nem nagyon látom, mi van a set-nél, nem áll össze a fejemben.
A legjobb megoldás valóban az, ha mindent arra használunk, amire való. Kivéve persze a template, mert azt template metaprogramming-ra is.
Igen, de hát az emplace pont erre van, hogy meghívja helyetted a konstruktort, még ha explicit is. Pont az ilyen baklövések miatt nem kéne push_back helyett is emplace-t használni, ahogy megállapítottuk
-
amtibacsi
aktív tag
Elnézést, ha rossz helyen járok, de nem találtam kunyerálós topicot. Szükségem lenne egy olyan programra, ami a paraméterben megadott időközönként ellenőrizné a z xp vagy win7 gépen lévő hangerőt és kikapcsolt hangerőt találva visszaállítaná egy szintén paraméterben megadott értékre. Pl. soundon.exe 100 300 azt jelentené, hogy 300 másodpercenként (5 percenként) megvizsgálná a hangerőt és amennyiben 0-án áll, akkor 100%-ra állítaná. Tudna ebben nekem valaki segíteni ? Bízom benne, hogy nem egy több hónapos programozást igénylő feladat
Előre is köszönöm, ha valaki megpróbál segíteni. Programozni sajnos nem tudok 
-
EQMontoya
veterán
válasz
dobragab
#3518
üzenetére
Egy szempontot kihagytál, már ha nem csak vektorról van szó.
Mégpedig azt az esetet, amikor az emplace lehet sikertelen: pl. setbe beszúrás. Ott jelentős különbségek vannak.Egyébként a move ctor témája érdekes, de ezzel sok probléma van. Ugye a legfőbb ok a nem generálódásra a user-defined copy ctr, ami elég gyakori. És amikor egy régi kódot átvisznek c++11-re, ott a pék se fogja utólag megkeresni és megírogatni..
A push_back vs. emplace_back témakörre: szerintem alapvetően másra szánták, és itt a jogászokhoz hasonlóan úgy gondolkodom, hogy nem csak az a lényeg, hogy pontosan hogyan működik betűről betűre, hanem hogy mire szánták. Márpedig ez itt szerintem jól jelzi a különbséget: push_back, ha már létezőt akarsz belerakni, emplace pedig ha benne akarsz konstruálni.
Ezzel pedig nagy bakot sem lehet lőni.A unique_ptr-es példára reflektálva: persze, ott nem az emplace_back a hibás alapvetően, de a unique_ptr<T> (T *p) egy explicit ctor! Tehát az emplace_back itt csúnyán elfedi, hogy Te épp hatalmas hülyeséget készülsz csinálni. Olyat, ami amúgy le sem fordulna.
-
dobragab
addikt
válasz
EQMontoya
#3502
üzenetére
Csak elkészült ez a válasz, túl régóta írom.
Az emplace_back veszélyét szerintem az első világítja meg legjobban. Nem te hívod meg a konstruktort, így történhetnek olyan konverziók, amit nem szeretnénk.
A második példában az igazi körmös nem az emplace_back, hanem a RAII megsértéséért jár. Sőt, rosszabb: RAII és raw pointer keverése. Ugye resource acquisition is initialization lenne, csakhogy a foglalás után pakolod bele egy unique_ptr-be, itt épp implicit módon.
Ha azt vesszük, hogy a vector deklarációja zömmel három forrásfájllal és 2000 sorral arrébb van, mint ahol belepakolsz, és lehet, hogy rosszul emlékszel, hogy az most A*-ot, vagy unique_ptr<A>-t tartalmaz. push_back-nél ha rosszul emlékszel, a fordító hörögve kiszáll.
Szóval a második esetért közvetve az emplace_back felelős, közvetlenül az, aki nem emlékszik, hogy ott unique_ptr van. Általános esetben is, az emplace_back-nél nem mindig kell tudnod, hogy temporális vagy létező cuccot akarsz-e belerakni, és ez itt a fő veszélyforrás.
Engem kísértetiesen emlékeztet a kérdés a C-s NULL és a 0 esetére, a hatékonyságot kivéve. Mindenhova írhatsz 0-t, ahova NULL-t, de fordítva nem igaz. Most ne keverjük ide a printf-et, talán az az egy kivétel van. Mégis, az olvashatóság kedvéért pointereknél NULL-t, egészeknél 0-t írunk, pedig írhatnánk mindenhova 0-t. Ugyanígy, az olvashatóság kedvéért létező objektumnál tessék push_back-et írni, hogy biztosak lehessünk benne, ott tényleg létező objektumról van szó.
Ennyi indok bőven elég, hogy push_back helyett ne használjunk emplace_back-et.
Továbbmegyek: van egyáltalán létjogosultsága az emplace_back-nek?Ha egy már létező objektumot akarsz belepakolni, a kettő pont ugyanannyira hatékony, ugyanaz történik. Megnéztem, mi a helyzet abban az esetben is, amire az emplace_back elsődlegesen való: temporális objektumnál. Igazából arra ment ki a játék, hogy ilyenkor jobb-e az emplace_back, mint a push_back kiírt konstruktorhívással. Azért mégis csak jobban látni, hogy ott egy temporális objektumot pakolunk bele a vektorba, ha oda van írva.
Ilyenkor szoktam elővenni a Noisy osztályt, ami mindig kiírja, mikor mi történik vele, és számolja, hány példány van belőle, amúgy semmi másra nem jó. Itt a teljes forráskód, a Noisy túl hosszú ahhoz, hogy gátlástalanul bemásoljam, ide csak a lényeget hoztam.
int main()
{
std::vector<Noisy> vec;
vec.reserve (1000);
Noisy n1(1);
vec.emplace_back(n1);
Noisy n2(2);
vec.push_back(n2);
vec.emplace_back(Noisy(3));
vec.push_back (Noisy(4));
vec.emplace_back(5);
}Az elején azért van ott a ronda reserve, hogy ne legyen átméreteződés, az csak összezavar minket.
Az n1 és az n2 esetében kottára ugyanaz történik, ahogy el is várjuk, copy ctor. Noisy(3) és Noisy(4) is egyforma, move ctor. Az igazán érdekes a 4-es és 5-ös összehasonlítása. Annyit nyertünk az 5-össel a 4-eshez képest, hogy egy move ctorral és egy ki-move-olt objektum destruktorával kevesebb. Ezen spórolni meg igencsak barbár dolog C++11 óta.
Ha kikommenteled a move ctort, akkor a fordító sem generál - mert írtunk destruktort -, így a copy ctor hívódik, tehát a push_back lényegesen lassabb lesz.
És mivel az emplace_back eleve C++11, így jó eséllyel van move ctora a tárolt cuccnak. Akkor van igazán értelme az emplace_back-nek, ha nincs move ctor, ilyen-olyan okból. Nem is lehet neki jó move ctort írni - ilyet nehezen tudok elképzelni, de C++-ban semmit nem zárok ki -, vagy C++98-as, nem módosítható API-ból jön.
Ha nincs move ctor, a hatékonyság számít annyit, hogy szerintem elfogadható az emplace_back. Egyéb esetben én azt mondom, fordítva kéne: emplace_back helyett is push_back-et használni: fontosabb az, hogy lásd kiírva a ctort, mint a move ctor overhead-je.
Akkor viszont egy másik probléma jön elő: ha van move ctor, akkor push_back, ha nincs, emplace_back. Ez kb. ugyanolyan rossz, mint az eredeti probléma, szóval temporális objektumra egységesen kéne a kettő közül választani. Nézzük meg a várható kockázatokat és a nyereséget:
push_back: ha nincs move ctor, lassú, de jól olvasható és egyértelmű
emplace_back: ha nincs move ctor, gyorsabb, néhány karakterrel rövidebb. Várható kockázat: egy elrontott emplace_back miatt végtelen debuggolás...Szóval én azt mondom, temporális objektumnál az API függvényében kéne dönteni, hogy az adott projektben melyik. De létező objektumra egész biztosan push_back.
-
#3517
MasterMark
titán
dobragab
#3516
MasterMark
titán
válasz
dobragab
#3516
üzenetére
Köszi.
Így már majdnem jó, még a while előtt olvasok egyet a stringstream-ből.
A good az működik ha több adat jön még utána, de ha csak az első elem van (akkor ugye az kellene, hogy a while-ba bele se menjen) az már nem jó.Én is erre gondoltam, hogy a stringstream végét nem jól látja, épp ezért kérdeztem, hogy ugyanúgy van-e mint a file. De akkor nem teljesen.
-
#3516
dobragab
addikt
MasterMark
#3515
dobragab
addikt
válasz
MasterMark
#3515
üzenetére
Szerintem EOF miatt, stringstream és fájl esetén máshogy lehet az EOF kezelés. EZT nézegesd.
Amúgy ez is szóba jöhet, ha mondjuk több beolvasás eredményét kell egyszerre ellenőrizned:
while(is.good()) {
// ...
}De ez csak tipp, pontosan nem néztem utána.
-
#3514
dobragab
addikt
MasterMark
#3513
dobragab
addikt
válasz
MasterMark
#3513
üzenetére
Jáj. Erre való az, hogy az istream tud bool-ra konvertálódni. Illetve C++98-ban nem is bool-ra, de úgy lehet használni, mintha. Ez más téma, és gány.
while (ss >> in){
// ...
} -
#3512
dobragab
addikt
MasterMark
#3511
dobragab
addikt
válasz
MasterMark
#3511
üzenetére
Elvileg ugyanúgy, elvégre mindkettő std::istream vagy std::ostream leszármazott.
-
#3511
MasterMark
titán
MasterMark
titán
Üdv
A stringstream nem pont ugyanúgy működik mintha szöveges fájlból olvasnék?
-
dobragab
addikt
Prog2-höz a sima rand() bőven elég, amúgy nem tudom, hogy nem jutott eszedbe, Czirkos kb. 3-4. előadáson már használta prog1-en.
(#3505) Jester01A Cporta egy nullptr-től is kiakad.
(#3506) dabadab
Azaz. Ha épp nem debuggolsz, a main elejére még illik egy ilyet:
srand(time(NULL)); -
-
r4z
nagyúr
C++11 nélkül hogyan generáljak egy ciklusban két különböző random számot?
Jelenleg így sikerült, de ez a megoldás nem engedélyezett
Cikluson kívüli rész:
std::random_device r;
std::random_device c;
std::mt19937 genr(r());
std::mt19937 genc(c());
std::uniform_int_distribution<> randrow(1, 8);
std::uniform_int_distribution<> randcol(0, 7);Cikluson belüli:
col = randcol(genc);
row = randrow(genr);krvnydt,cporta
-
EQMontoya
veterán
Beszéljünk az emplace_back vs. push_back témakörről.
Tegnap felvetette az egyik arc, hogy használjunk mindenhol emplace-t, elvégre úgyis rendelkeznie kell az osztálynak copy-construktorral, tehát mindenhol olyan gyors lesz, vagy gyorsabb, mint a push_back.Nekem ez így annyira nem tetszett, mert az emplace helyben konstruálásra való, az igazából egy elég fura mellékhatás, hogy copy-ctr miatt igazából használható push_back helyett is.
Jött a kérés, hogy akkor írjak olyan esetet, amikor nem ajánlott az emplace. Írtam:
#include <iostream>
#include <vector>
#include <memory>
class A
{
public:
bool mb;
explicit A(bool b): mb(b) {}
};
int main()
{
A* ap = new A(false);
std::vector<A> vec;
vec.emplace_back(ap); //this compiles without warning - sooooo bad!
//vec.push_back(ap);
std::vector<std::unique_ptr<A>> uptr_vec;
uptr_vec.emplace_back(ap);
delete ap; //busted
}
Ennyire nem jó helyre jött volna? 
Egyébként ismeritek az Effective C++ könyvet? Abban találkoztam ezzel az első Item-nél.
BTW tegnap meglett a Prog nyelvek C++, jöhet a számgraf meg az oprendszerek 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ú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!
- Milyen autót vegyek?
- Milyen okostelefont vegyek?
- TV antenna és jelerősítés
- Autós topik
- Úgy tér vissza a Commodore 64, ahogy titkon mindenki várja
- DUNE médialejátszók topicja
- gban: Ingyen kellene, de tegnapra
- Építő/felújító topik
- Linux kezdőknek
- Samsung Galaxy Z Flip7 - kis fogyás is sokat jelent
- További aktív témák...
- Macbook M1 Pro 8GB RAM 256GB SSD
- Eladó Vagy Csere Samsung Galaxy Z Fold 4
- EVGA SuperNOVA 750W GT 80 Plus Gold full moduláris tápegység / 53 hónap Alza.hu garancia
- Surface Laptop 4 Touch 13.5 Retina Ryzen7 4980U 4.4Ghz 16GB 512GB Radeon RX Vega8 Win11 Pro Garancia
- Gigabyte AORUS B550I PRO AX ITX Rev 1.2 / Beszámítás OK!
- Bomba ár! HP EliteBook 840 G4 - i5-7GEN I 16GB I 256GB SSD I 14" FHD Touch I Cam I W10 I Garancia!
- Bomba ár! Lenovo ThinkPad L13 G3 - i5-1245U I 16GB I 256SSD I 13,3" FHD Touch I NBD Gari!
- Bomba ár! Dell Latitude E6400 - Intel P8400 I 3GB I 160GB I 14,1" I Intel VGA I Garancia!
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB RAM RTX 5060 Ti 16GB GAMER PC termékbeszámítással
- MacBook felvásárlás!! MacBook, MacBook Air, MacBook Pro
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest