Pointer semantics in CTFE

Don Clugston dac at nospam.com
Tue May 29 06:29:35 PDT 2012

On 27/05/12 02:45, Walter Bright wrote:
> On 5/26/2012 3:59 AM, Don wrote:
>> Yes, that's what happens now. But that doesn't help the programmer.
>> If it is inside, no problem, the expression is true. But if it is not
>> inside,
>> the expression is not false -- it's a compile-time error.
> Ok, I understand now what you meant.
>> So you can't use it as a test for if it is inside the same object.
>> I was confused about how memmove can work in C without relying on
>> undefined
>> behaviour. But I just read
>> http://www.cplusplus.com/reference/clibrary/cstring/memcpy/
>> which defines it in terms of an intermediate buffer.
>> So maybe, the current CTFE implementation is _exactly_ consistent with
>> the C
>> spec. If that's true, though, I find it pretty incredible that there
>> is no way
>> to find out if a pointers points a particular array, even if you have
>> pointers
>> to both the start and end of that array.
>> (OK, I guess you can iterate from start to end, checking for equality,
>> but ..
>> bleah .. it's a terrible abstraction inversion).
> You could implement it as simply comparing the addresses - you'd be no
> worse off than C is, and you would get the correct answer for pointers
> both in and out of the array without needing special cases.

I think that's a no-go.
Implementation-specific behaviour at runtime is bad enough, but at 
compile time, it's truly horrible. Consider that any change to unrelated 
code can change the results. Something that makes it really terrible is 
that the same function can be called in CTFE once before inlining, and 
once after. Good luck tracking that down.
And at runtime, you have a debugger.

It's not hard to make it work in all cases of:

one-sided-comparison && one-sided-comparison
one-sided-comparison || one-sided-comparison

     ptr_expression RELOP ptr_expression
     ! one-sided-comparision


where ptr_expression is any expression of type pointer.

And by all cases, I really mean all (the code for the four pointer 
expressions need not having anything in common).

It's only when you allow other expressions to be present, that things 
get hairy.

More information about the Digitalmars-d mailing list