- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Steam Deck
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Eltűntek a mobil GPU-k az AMD és az Intel útitervéből is
- Csendes hegyre kalauzol az új Arc meghajtó
- Milyen nyomtatót vegyek?
- Milyen videókártyát?
- Milyen Android TV boxot vegyek?
- Milyen monitort vegyek?
- Milyen alaplapot vegyek?
Új hozzászólás Aktív témák
-
jattila48
aktív tag
Az általam írt optimalizáció megvalósításában valószínűleg annak eldöntése lehet a legnehezebb (esetleg lehetetlen), hogy van-e a post verziónak mellékhatása. A szokásos megvalósításban ez a mellékhatás csak a copy ctor-ban lehet. Elképzelhető, hogy a szabvány nem engedi meg a mellékhatás kioptimalizálását (ellentétben az RVO-val, ahol a copy ctor mellékhatását engedi figyelmen kívül hagyni). Ez esetben tényleg nem ez a járható út. Ha viszont a post verziónak van mellékhatása, akkor a programozónak főleg foglalkoznia kell azzal, hogy melyiket használja.
„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
Ha már a Google-nál dolgozol, nyilván ismered:
Google C++ Style Guide
Preincrement and Predecrement
Use prefix form (++i) of the increment and decrement operators with iterators and other template objects.
When a variable is incremented (++i or i++) or decremented (--i or i--) and the value of the expression is not used, one must decide whether to preincrement (decrement) or postincrement (decrement).
When the return value is ignored, the "pre" form (++i) is never less efficient than the "post" form (i++), and is often more efficient. This is because post-increment (or decrement) requires a copy of i to be made, which is the value of the expression. If i is an iterator or other non-scalar type, copying i could be expensive. Since the two types of increment behave the same when the value is ignored, why not just always pre-increment?
The tradition developed, in C, of using post-increment when the expression value is not used, especially in for loops. Some find post-increment easier to read, since the "subject" (i) precedes the "verb" (++), just like in English.
For simple scalar (non-object) values there is no reason to prefer one form and we allow either. For iterators and other template types, use pre-increment.
Úgy látszik, hogy a céged mégiscsak elvárja, hogy foglalkozz ezzel.
„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
Nem feltétlenül iterátorra gondoltam. Más bonyolultabb objektumnak is lehet inkrementáló operátora, amit esetleg tényleg nem lehet inline-olni (más kérdés, hogy van-e értelme). Az RVO-t csak arra írtam, hogy ha azt a fordító (és nem külön menetben az optimalizáló) végzi, akkor akár ezt is elvégezheti, amit írtam, Egyáltalán nem biztos hogy megcsinálja, de számomra ez még egyszerűbb feladatnak tűnik mint az RVO. Persze az igaz, hogy csak akkor, ha a ctor, dtor-nak nincs mellékhatása.
"Ahhoz, hogy úgy működjön a fordító, hogy detektálja, hogy most ki lehet cserélni a pre-t post-ra, úgy, hogy minden esetben működjön, ahogy te leírod, nagyon okosnak kell lennie"
Ahol nem használja a post visszatérő értékét ott kicseréli, máshol meg nem. Vagy ez nem ilyen egyszerű?
Akárhogy is van, azzal hogy "akkor ne foglalkozz vele, mert nem ér annyit", nem értek egyet. Szerintem ez nem különösebben teszi próbára a programozót, hogy adott esetben el tudja dönteni, tényleg szüksége van-e a post verzióra, vagy elég a pre is. Vagyis igenis foglalkozzon vele , mert megér annyit. Szerintem ezt hogy a post lassabb lehet, illik tudni egy programozónak. Kód review-ban én szóvá tenném, míg azt a valóban szerencsétlen bool értékadást nem.
Más, nem csak neked címezve:
Makrók és template metaprogramming használatával olyan programot szeretnék írni, amit újra fordítva, az előzőleg fordítottal funkcionálisan megegyező, azonban bináris kódjában erősen különböző kódot kapok. Ez egy kicsit bonyolult mondat lett, tehát a lényeg: makrókkal és TMP-vel bináris kód obfuszkáció. Hatékonyság nem lényeg, lehet bele (sőt...) redundáns kódot injektálni, hadd legyen minél nehezebben követhető a kód. Olyanokra gondoltam mint értékadás, függvényhívás, bool kifejezések bonyolítása, loop unrolling, stb. Ha van ezzel kapcsolatban ötletetek, ne tartsátok magatokban. Ja, és ne akarjatok lebeszélni róla, hogy ugyan minek ez nekem. Köszi előre is.
„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár
Ú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!
- Macbook Air M1 2020 16GB Ram 256gb SSD 98%akku, megvigyázott
- Hibás! Westen Pulsar Green 24 kéményes kombi gázkazán
- KTC M27T20 - 27" HDR Mini Led Gaming monitor
- Gamer PC eladó! VÍZHŰTÉS! I5-9600K Tuning/32GB Predator RAM/RTX 2060/500GB SSD + 500GB HDD
- Eladó konfig! I7-12700 1TB SSD 32GB DDR4 RX6800 16GB!
Állásajánlatok
Cég: Marketing Budget
Város: Budapest