Suppose I have a struct called "Hum":


struct Hum
{
int du;
}


Now I have the following code:


Hum *hum = NULL;

//Condition.
if(hum && hum->du == 0)
{
//Do stuff...
}
else
{
//Error!
}


My doubt is this: If the first condition is not met, is the following condition discarded right away without having it checked? On the case where "hum == NULL", an error would obviously occur if the second condition is checked.

I've done tests with this and concluded the answer to be no. But would like to know if that's applied to all cases.

Thanks

I appreciate the reply and link alvaro, though I didn't quite understand your note since I'm brazillian , but I get the point.

Thanks again.

É a mesma coisa em Português: A tradução correta de "dúvida" neste contexto é "question", não "doubt".

I lived in Rio for three years when I was a kid. De nada.

Um compatriota entao, é bom saber que nao sou o unico por aqui... : )

I don't live in Rio but visit it every now and then, it's a great city!

Just for completeness it should be pointed out that && and || will evaluate both sides, causing a dereference to the pointer and a crash, if operators && or || are overloaded.

It doesn’t mean you should go out of your way to write code that is safe under such a condition, it means never ever overload operators && or ||.


L. Spiro

[quote name='L. Spiro' timestamp='1338459103' post='4944924']
It doesn’t mean you should go out of your way to write code that is safe under such a condition, it means never ever overload operators && or ||.

... or operator , (for the same reason).
[/quote]
Won't the comma operator always evaluate both the left side and the right side though (i.e. there shouldn't be any short circuiting, right?)? I don't think (guessing) it guarantees the order in which it evaluates its arguments when overloaded though, which certainly could be problematic (and is what I think you're pointing out).

[quote name='Cornstalks' timestamp='1338475494' post='4944993']
[quote name='alvaro' timestamp='1338473232' post='4944982']
[quote name='L. Spiro' timestamp='1338459103' post='4944924']
It doesn’t mean you should go out of your way to write code that is safe under such a condition, it means never ever overload operators && or ||.

... or operator , (for the same reason).
[/quote]
Won't the comma operator always evaluate both the left side and the right side though (i.e. there shouldn't be any short circuiting, right?)? I don't think (guessing) it guarantees the order in which it evaluates its arguments when overloaded though, which certainly could be problematic (and is what I think you're pointing out).
[/quote]
I think he just meant it as a general comment that the comma operator changes behavior when overloaded, like && and ||, not whether the two sides are evaluated or not. The built in comma operator is a sequence point, but the overloaded operator is a function call and subject to the usual rules about order of evaluation.
[/quote]
Yes, that's what I think he meant. Maybe I just misunderstood what "for the same reason" implies, but it makes it sound like the reason is short-circuiting (or not short-circuiting), and I was just trying to clarify that the "same reason" here is that it will screw up programmers because the evaluation of the arguments is different than what most would expect, and not the short-circuiting reason.