Sign in to follow this  

Lazy evaluation [c++]

This topic is 4274 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

I just want to be sure of this... we can trust that this is always safe, correct?
if( i < ARRAY_SIZE && array[i] == 'z' )
{
   ...
}

(That is, 'array' shouldn't have an out-of-bounds error, ever)

Share this post


Link to post
Share on other sites
Quote:
Original post by Xai
C and C++ are 100% guaranteed to perform short-circuit left-to-right evaluation ... so you are safe


Is that stipulated by the standard?

GCS584

Share this post


Link to post
Share on other sites
Quote:
Original post by gcs584
Quote:
Original post by Xai
C and C++ are 100% guaranteed to perform short-circuit left-to-right evaluation ... so you are safe


Is that stipulated by the standard?

GCS584


Yes, even though I can't quote it. =)

Share this post


Link to post
Share on other sites
Actually I need to add another condition: "and provided there is not an overloaded operator&& compatible with the types resulting from the expressions i < ARRAY_SIZE and array[i] == 'z'".

The built in operator&& is guaranteed by the standard to provide left-to-right evaluation with the right hand side not being evaluated if the left hand side evaluates to true. Overloaded versions of operator&& are functions and therefore do not provide guaranteed left-to-right evaluation.
Quote:
C++ Standard, Final Draft, Section 5.14, Paragraph 1
The && operator groups left-to-right. The operands are both implicitly converted to type bool (4). The result is true if both operands are true and false otherwise. Unlike &, && guarantees left-to-right evaluation: the second operand is not evaluated if the first operand is false.
Quote:
C++ Standard, Final Draft, Section 5, Paragraph 2
Operators can be overloaded, that is, given meaning when applied to expressions of class type (9) or enumeration type (7.2). Uses of overloaded operators are transformed into function calls as described in 13.5. Overloaded operators obey the rules for syntax specified in this clause, but the requirements of operand type, lvalue, and evaluation order are replaced by the rules for function call. Relations between operators, such as ++a meaning a+=1, are not guaranteed for overloaded operators (13.5), and are not guaranteed for
operands of type bool. —end note]

Σnigma

Share this post


Link to post
Share on other sites
If array is an actual array (and not a pointer), then:

if (i >= 0 && i < sizeof(array)/sizeof(array[0]) && array[i]=='z') {
}

works nicely.

You could also try:

bool bounded(int min, int value, int max) {
return value >= min && value < max;
}

template<typename T>
bool InBounds(std::vector<T> const& v, int i) {
return bounded(0, i, v.size());
}
template<typename A, int n>
bool InBounds(A const& a[n], int i) {
return bounded(0, i, n);
}


And then:

if (InBounds(array, i) && array[i] == 'z') {
}

works nicely.

Share this post


Link to post
Share on other sites
I don't think he needed to bound the array ... I am working on the assumption that he already understands that if his input data is suspect, a negative index would blow up his world. I took this as the age old "is it really safe to do the test before the use, in an if ... or are all these samples I've seen just getting lucky?" kinda question ..

Course, with Enigma's post (thanks BTW), the water gets murkier because of the overloading thing ... and I think that's going on my very short list of things I'm not sure the standard should have done (If writing an overload MUST change the semantics of an operation - as opposed to MIGHT - they should not have allowed overloading for that operator). But I guess it doesn't matter as long as we programmer's are informed and choose to avoid using the constructs we aren't wise enough to handle properly.

Time will tell.

Share this post


Link to post
Share on other sites

This topic is 4274 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this