- 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
- Vezetékes FEJhallgatók
- Sony MILC fényképezőgépcsalád
- VR topik (Oculus Rift, stb.)
- Modern monitorokra köthető 3dfx Voodoo kártya a fészerből
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Milyen cserélhető objektíves gépet?
- ZIDOO médialejátszók
- Azonnali informatikai kérdések órája
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Milyen asztali (teljes vagy fél-) gépet vegyek?
Hirdetés
-
Az Apple iPadOS-t is megrendszabályozza az EU
it Az EB közölte: az Apple iPad táblagépekre írt iPadOS rendszere is kapuőrnek számít, az üzleti felhasználókra gyakorolt fontossága miatt.
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
-
Már tudjuk, hogy mikor jön az idei Xbox Games Showcase
gp A showt egy külön Direct előadás követi, ami szinte biztosan az idei Call of Duty lelepelzése lesz.
Új hozzászólás Aktív témák
-
dobragab
addikt
-
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
}[ Szerkesztve ]
Same rules apply!
-
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
[ Szerkesztve ]
I don't love people. I love 911s, Astral Projection and french fries, in that order.
-
r4z
nagyúr
Sikerült:
unsigned int PRNG()
{
static unsigned int seed = 5323;
seed = (8253729 * seed + 2396403);
return seed % 32767;
}ciklusban:
col = PRNG()%8;
row = PRNG()%8 + 1;Jester01: A C++11 elemek általában, mert a beadóportál elavult fordítót használ.
[ Szerkesztve ]
I don't love people. I love 911s, Astral Projection and french fries, in that order.
-
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));[ Szerkesztve ]
Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.
-
-
MasterMark
titán
Üdv
A stringstream nem pont ugyanúgy működik mintha szöveges fájlból olvasnék?
Switch Tax
-
dobragab
addikt
válasz MasterMark #3511 üzenetére
Elvileg ugyanúgy, elvégre mindkettő std::istream vagy std::ostream leszármazott.
Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.
-
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){
// ...
}Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.
-
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.
Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.
-
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.
Switch Tax
-
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.
Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.
-
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.
[ Szerkesztve ]
Same rules apply!
-
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
-
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
Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.
-
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.
Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.
-
-
dobragab
addikt
Jöttök holnap?
Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.
-
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.
C programmers never die, they are just cast into void.
-
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.[ Szerkesztve ]
Same rules apply!
-
dobragab
addikt
(#3546) dabadab
Ejnye-bejnye, meg se ismernéd a Mestert? Ezt a frizurát nehéz lenne eltévesztenem.
Amúgy aki nem ismerne, a kérdésem 1:49:50-nél hangzott el
[ Szerkesztve ]
Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.
-
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
Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.
-
Ú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!
- 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
- ATI RADEON RX 480 -8 gb DDR5 256 bit videokártya