On 26.05.2012 01:09, Walter Bright wrote:
On 5/24/2012 11:50 PM, Don Clugston wrote:
Opinions?


My experience with such special cases is that users lose the ability to
reason about what code will work in CTFE and what will not. Its
operation will become a magical, unknowable black box. Meanwhile, you'll
be endlessly chasing more special cases and rainbows.

I suggest not supporting it unless it can be done in the general case.

One solution might be to attach to each CTFE pointer a reference to the
object it is pointing into. Then, pointer comparisons within the same
object can work, and comparing pointers from different objects can
explicitly and predictably be not supported.

That is exactly how it works right now.

The problem is, if pstart and pend point to the beginning and end of an array, then given another pointer q, there is AFAIK no defined way in C for checking if q is between pstart and pend, even though I'm sure everyone does it. (eg, I don't know how to implement memcpy otherwise). If q is part of that array, (q >= pstart && q <= pend) is well-defined, and returns true.
But if it isn't part of that array, q >= pstart is undefined.

In reality of course, if q is unrelated to the array then EITHER q < pstart, OR q > pend. So (q >= pstart && q <= pend) is ALWAYS false, and the result is completely predictable.

ie, the full expression can be well-defined even though its two subexpressions are not.

This can be implemented.
Given an expression like q >= pstart, where p and q are unrelated, it's possible to make it have the value 'false_or_undefined'. If it is anded with another expression that is also false_or_undefined, and goes the other direction ( q <= pend) , then the whole thing is false. Otherwise, it generates an error.

The reason it would have to be a special case is because of things like:
bool b = false;
q >= start && ( b = true, true) && q <= end
which is undefined because the result of the first comparison has been stored. So it would only be valid for one-comparison-in-each-direction-anded-together (and the equivalent for ||).

Reply via email to