[ aleksazr @ 14.08.2016. 13:04 ] @
U okviru neke rutine imam deklarisanu varijablu v i odmah je inicijalizujem rutinom getINT():

int v = getINT();

getINT neće nikad vratiti nulu, kako to da kažem kompajleru, da varijabla v nije nula?

Mogu ovako, ali to generiše kod:
if (v == 0) return; // odavde pa nadalje, kompajler zna da je v != 0

Može nešto bez generisanja koda?
[ X Files @ 14.08.2016. 14:20 ] @
Ne znam tačno šta želiš da postigneš, ali svakako pogledaj i ASSERT:

http://www.cplusplus.com/reference/cassert/assert/
[ aleksazr @ 14.08.2016. 15:16 ] @
Odprilike znam šta radi ASSERT, ali to je C++.
Trebao sam napisati u tekstu da je C, a ne samo u subjectu.
Hvala u svakom slučaju.

Da uverim kompajler da je varijabla v != 0, kako on ne bi morao da testira.
Hteo sam da koristim FOR petlju, ali moraću DO-WHILE.
Nije da bi se dobilo nešto na brzini, ali ako ja već znam da ne može biti nula - zašto da testira.

[ Branimir Maksimovic @ 14.08.2016. 23:56 ] @
1. assert je C...
2. Kompajler nece generisati kod specificno za nulu...
[ Mihajlo Cvetanović @ 15.08.2016. 14:10 ] @
Kakvo je to neželjeno testiranje na nulu, koje kompajler radi? Misliš na for petlju? Najbolje je da je pretvoriš u do-while petlju, jer je tako očigledno šta želiš da postigneš. Programski kod ne služi samo kompajleru, nego i tebi, i ne samo sadašnjem tebi nego i budućem tebi, koji će zagarantovano zaboraviti neke detalje u vezi s kodom koje sada imaš u glavi. do-while petlja je najbolji način da kažeš i kompajleru i budućem tebi da ta petlja ne treba da testira uslov na početku petlje, nego na kraju.
[ negyxo @ 15.08.2016. 19:04 ] @
Za tako nesto najbolje da se prebacis u C++. Posto ces tamo moci prilicno lako da postavis constraint prosto dodavanjem nove definicije. Recimo mozes da definises klasu koja prima int ali koji je uvek veci od nula (to proveris u konstruktoru) pa zatim nadalje u programu koristis uvek tu klasu gde ti treba int > 0. To je sustina type systema, pride C++ ti omogucava da prosledjujes po referenci pa samim tim mozes biti skoro 100% siguran da klasa (tj. instanca koju budes prosledjivao) nece biti null (osim ako ne radis neke egzibicije sa castingom). Naravno ovo moze biti overkill za neke stvari, posto klasa ima veci overhead u odnosu na prost integer, ali to biras sam - performance vs safety :)
[ aleksazr @ 16.08.2016. 17:08 ] @
Da, mislio sam na for petlju... i prešao sam na do-while.

Nisam znao da assert ima i za C... ali, koliko znam, assert proverava run-time,
a to sam hteo da izbegnem. (napisao sam: Može nešto bez generisanja koda?)

A C++ bih radije izbegao :)
[ aleksazr @ 27.09.2021. 09:41 ] @
__assume(v != 0);

msdn
[ Nedeljko @ 30.09.2021. 20:49 ] @
Najbolje rešenje je ne reći to kompajleru nikako, već ubaciti runtime proveru

Code (c):

int v = getINT();

assert(v!=0);
// some code

Ubacivanjem informacije kompajleru se uvodi više problema nego što se rešava. Mala je to optimizacija, a problem koji se uvodi je što nema garancija da će taj uslov uvek biti zadovoljen.

Danas je to tako, ali projekat će se sutra menjati, pa če 0 postati moguća povratna vrednost funkcije, pa će programski kod koji sledi iza dodele vrednosti promenljivoj v postati nekorektan, jer ne obrađuje slučaj v==0 kako treba.

Ukoliko se ubaci assert, onda će se zaista trošiti neznatno vreme na runtime proveru, ali će u navedenom slučlaju prilikom runtime testiranja program da zvekne i napisaće koji je assert pukao, pa će se otići na to mesto i promeniće se programski kod tako da obrađuje navedeni slučaj kako treba.

Ovde se ubacivanjem __assume proizvodi više problema nego što se rešava. Dobija se neznatno na performanasama, ali od tih par ciklusa je važnije da se projekat završi do kraja, da radi korektno i da se može lako održavati. Ja sam uvek za optimizaciju i nerazbacivanje resursa, ali treba voditi računa i o prioritetima.
[ Burgos @ 02.10.2021. 22:31 ] @
Slažem se sa Nedeljkom. Herb Sutter je prošle godine napisao papir u kome opisuje iskustvo MSVC frontend-a i __assume:

http://www.open-std.org/jtc1/s...1/docs/papers/2020/p2064r0.pdf

Citat:
The only large-scale case I know of that did assume assertions was in the Microsoft C++ compiler front-end and
back-end. In summary: It arose unintentionally (the intent was the reverse, to assert assumptions), caused relia-
bility problems, and has been removed (with minor performance gains).


Citat:
Much to our surprise, the C1xx front end actually got a 1-2% faster with __assume statements
removed.


Strane 4, 5 i 6.