Kioptimalizálja a fordító, vagy nem?

Ha a cond erteke nem fix a ckrdito szamara, akkor meg fogja hivni az egyik fuggvenyt. A ?: operator etekadasra van, de talan igy is leforditja a c++. A tobbi fejlesztovel ne szurj ki hogy utobbi formaban irod. :) 

gcc (Debian 6.3.0-18+deb9u1) byte-ra pontosan ugyanazt forditja belole, de en is az elsot ajanlom, olvashatobb a kod tole.

Optimalizált code esetén felismeri azt is, hogy ugyanaz a kód: godbolt példa. (Pedig ez csak O2.)

Ha ez a feltételezés

A második alak esetén a visszatérési érték nem lesz változónak átadva. Ezért kioptimalizálja a fordító[...]?

esetleg megállja a helyét, akkor azon töprengek, hogy vajon ezen mit kéne hogy változtasson a ?: operátor hiánya... vagyis ha sizmplán annyi a kód, hogy meghívsz egy függvényt és fittyet hánysz annak visszatérési értékére, avagy eleve void típusú a függvény. Mert akkor úgy lenne logikus, hogy azt is kioptimalizálhatná, nem? Hiszen ott sem lesz „megörökítve” a visszatérési érték. Aminek nyilván semmi értelme nem volna.

Ja még valami: az if esetén se kerül sehova a fv-k visszatérési értéke, nem csak a ?: operátor használata esetén.

Én nagyon sokat használom a ? operátort, különösen áttekinthető a kód, ha egymásba ágyazott is-else-elif - fel kéne helyettesíteni.

pl:

      case 'B': bp_ndx=(data<ZMIFC->meadat.CHN[ndx].bpFlo[1])    ?    1 :
               (data<ZMIFC->meadat.CHN[ndx].bpFlo[2])    ?    2 :
               (data<ZMIFC->meadat.CHN[ndx].bpFlo[3])    ?    3 :
               (data<ZMIFC->meadat.CHN[ndx].bpFlo[4])    ?    4 :
               (data<ZMIFC->meadat.CHN[ndx].bpFlo[5])    ?    5 :
               (data<ZMIFC->meadat.CHN[ndx].bpFlo[6])    ?    6 :
               (data<ZMIFC->meadat.CHN[ndx].bpFlo[7])    ?    7 : 8;

(jelkarakterisztikát vizsgál)

Na most ez szerintem if-else párral rémálom lenne olvasás szempontjából Képzeljétek hozzá, hogy az én szövegszerkesztőmben a '?' jelek egymás alatt vannak (-:: 

Előfordulhat, hogy a ? operátor hatására jobb kód fordul. Soha nem vizsgáltam, de ezt írja a szakkönyv és én elhiszem neki.

Két apróság:

• a cond visszatérési értéke nem csak a ?: esetén nem kerül változóba, hanem az if szerkezet esetén sem,
• a cond visszatérési értékére mindkét esetben szükség van, hogy a logikai döntés meghozható legyen és ennek eredményeképp vagy az egyik, vagy a másik ág fusson, függetlenül attól, hogy az if/else vagy ?:. Tehát nem optimalizálható ki a cond futtatása egyik esetben sem.

Itt az egyik megoldás: https://c.godbolt.org/z/79nr4Pq4P
Egyúttal Rust-ban is: https://rust.godbolt.org/z/7znoWc3E9

És egy másik feladvány: keresd a ciklust az alábbiakban:
    https://c.godbolt.org/z/ch4T6v7rP
    https://rust.godbolt.org/z/sWjd74e85

Legjobb tudásom szerint, nyugodtan használhatod a ? operátort elvileg. Gyakorlatilag elképzelhető olyan fordító ami érdekes viselkedést produkál. De az ember nem nagyon cserélgeti a fordítót, pláne nem projecten belül. Ez meg simán mehet a teszt kódba, ha új fordítót választanátok a következő projecthez.

Azoknál a kódoknál amit én írok ott az if-es szerkezet játszik, azokban a problémában az az olvashatóbb. Dehát kinek a pap, kinek a papné kezdetű mondás igaz ide is.

funct(...)
{
 return({ int z;if ( cond ) z=func1(); else z=func0(); z;});
}

Ha egyértelműen meg tud róla győződni a fordító, hogy nincsen mellékhatása (pl. nincs io, globális változó változtatása) a funkcióhívásodnak, akkor ki fogja "optimalizálni" - vagy inkább már fordítási időben figyelmeztet rá, hogy felesleges hívás.

Én inkább arra gondolok, hogy most(!) ok. Viszont a kompiler verzió váltásakor, jobb esetben warning -ot dob rosszabb esetben ki optimalizálja és nem szól egy szót sem. Gondot okozhat, debug/trace esetén is.
30(?) éves munkálkodásom alatt sok különféle C trükköt láttam, de sok vezetett később nagyon nehezen azonosítható hibákhoz.
Egyébként ez még a szelídebb verziók egyike.

Egyébként, ha nincs több művelet a feltételek alatt, akkor a zárójeleket is elhagyhatod, azzal is rövidül kód. Megteheted, hogy csinálsz egy (akár globális) dummy -t amire minden ilyen kifejezés elküldheti az eredményt. Esetleg alkalmazhatsz ugrótáblát.

Hat, a torvény betűje szerint nincs különbség a ket forma között. A stilisztikai kerdes az inkább szubjektív, minden csapat el tudja dönteni, hogy mennyire szereti a kompakt kódot.

Az optimalizacio egy fokkal fogosabb. A C++ szabvány azt mondja, hogy a fordító bármilyen optimalizaciot megtehet, ami nem változtatja meg a program "megfigyelhető viselkedését" ("observable behaviour"). Szóval, ha a fuggvenynek nincs mellékhatása (funkcionális terminológiával elve "pure"), akkor a fordító kioptimalizálhatja a fuggvenyhivast. Az, hogy a fgv pure-nak találja a fordító vagy nem, az az optimalizacio minőségétől függ, a lényeg az, hogyha téved, akkor az impurity irányba tévedhet csak. Tehát lehet, hogy van egy pure fgv, amit az optimalizacio impure-nak tekint es nem eliminál, pedig a szabvány betűje szerint megteheti.

Mint minden jo szabály alól, ezalol is van kivétel, es az a kivétel éppen határos a felvetett problémával. Az úgynevezett RVO (Return Value Optimization), ami azt jelenti, hogy fuggvenybol visszaadott értek eseten a másolás (sot esetleges többszöri másolás) kioptimalizálható, meg akkor is, ha ez megváltoztatja az observable behaviour-t. Nem vagyok benne biztos, hogy ez egészen pontosan hogyan működik együtt azzal a helyzettel, amikor a visszatérési értek el lesz dobva. A konzervativ tippem az, hogyha a visszeteresi értek előállítása es destruktora pure, de a másolása impure, akkor meg mindig teljesen elhagyhato a fuggvenyhivas.

 Olvasnivalo a temaban:

https://en.wikipedia.org/wiki/Copy_elision

https://en.cppreference.com/w/cpp/language/as_if

A második link leírja, hogy egész pontosan milyen esetekben számít a program megfigyelhető viselkedése ugyanolyannak es mikor nem, szóval ezen nem kell spekulálni, a szabvány elég világosan beszel (mégha bonyolult is a terminológia).