<br><div class="gmail_quote">2009/6/20 Alin Popescu <span dir="ltr"><<a href="mailto:alinpopescu@live.com">alinpopescu@live.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So, my point is, la temele la so era absolut nevoie sa verificam in 'release' toate codurile de eroare? Banuiesc ca raspunsul<br>
va fii DA!. Este o intrebare semi-retorica.</blockquote><div><br>Assert e folosit pentru a verifica preconditiile, nu pentru a prinde cazurile de
erori normale ce pot aparea in timpul executiei (memorie plina in cazul
asta... bine, discutia e mai lunga pe Linux). In momentul cand <br>
<br>
In cazul alocarii memoriei, poti folosi perror("mesaj") pt. ca desi malloc nu e apel de sistem, se seteaza errno la ENOMEM.<br><br>Ca sa iti raspund la intrebare, verificatul erorilor in teme este un exercitiu, pentru a va invata Good Programming Practice.<br>
Intr-un program real, este important sa fii paranoic pentru a avea o aplicatie robusta. De accea assert e destul de inutil pentru ca vrei ca verificatul _erorilor_ ce pot aparea sa ramana si in release.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Din cate imi amintesc, assert nu incetineste aplicatia finala, pentru ca este scos odata ce aplicatia este compilata ca release.<br>
If-ul inseamna hazard de control, sageata albastra de la dreapta la stanga din cartea lui Patterson, a dus la branch prediction si multe complicatii.</blockquote><div><br>Asta este caz de micro optimizare inutila. Procesoarele de azi au branch prediction destul de bun, care poate fi chiar ajutat prin folosirea directivei __builtin_expect (likely si unlikely din kernel). In plus, la cateva sute de milioane de instructiuni pe secunda, un if nu conteaza.<br>
<br>Cosmin.<br></div></div>