• Advertisement
Sign in to follow this  

If condition question. C++

This topic is 2093 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
I appreciate the reply and link alvaro, though I didn't quite understand your note since I'm brazillian biggrin.png , but I get the point.

Thanks again.

Share this post


Link to post
Share on other sites
É 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. :)

Share this post


Link to post
Share on other sites

É 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. smile.png


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!

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

[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).

Share this post


Link to post
Share on other sites

[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.

Share this post


Link to post
Share on other sites

[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. Edited by Cornstalks

Share this post


Link to post
Share on other sites

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.

The reason refers to that the behavior of the overloaded operator is no the same as the built in operator, and therefore you should stay away from overloading it.

Share this post


Link to post
Share on other sites

The reason refers to that the behavior of the overloaded operator is no the same as the built in operator, and therefore you should stay away from overloading it.


That is exactly what I meant. I'm sorry I wasn't clear enough.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement