On 30/05/12 17:33, Michel Fortin wrote:
On 2012-05-30 14:44:37 +, Steven Schveighoffer
schvei...@yahoo.com said:
On Tue, 29 May 2012 13:35:12 -0400, Michel Fortin
michel.for...@michelf.com wrote:
Personally, I think it'd be much cleaner to go with some kind of
magic function than trying
On 29/05/12 16:20, Michel Fortin wrote:
On 2012-05-29 13:29:35 +, Don Clugston d...@nospam.com said:
On 27/05/12 02:45, Walter Bright wrote:
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
On 30/05/12 01:47, Mehrdad wrote:
Just a general note: going the make a special case for two comparisons
route won't work if, for example, someone decides to use a lambda for
comparing pointers.
You mean effectively like:
bool cmp(void *x, void *y)
{
return x y:
}
assert ( cmp(x, y)
On Tue, 29 May 2012 13:35:12 -0400, Michel Fortin
michel.for...@michelf.com wrote:
On 2012-05-29 15:09:00 +, Artur Skawina art.08...@gmail.com said:
int a[1024];
int[] da = a[0..1024];
if (whatever)
da = da[3..14];
if (something_else)
da = [42] ~ da;
// etc
On 2012-05-30 14:44:37 +, Steven Schveighoffer
schvei...@yahoo.com said:
On Tue, 29 May 2012 13:35:12 -0400, Michel Fortin
michel.for...@michelf.com wrote:
Personally, I think it'd be much cleaner to go with some kind of magic
function than trying to match the condition against a
On Wed, 30 May 2012 11:33:54 -0400, Michel Fortin
michel.for...@michelf.com wrote:
On 2012-05-30 14:44:37 +, Steven Schveighoffer
schvei...@yahoo.com said:
On Tue, 29 May 2012 13:35:12 -0400, Michel Fortin
michel.for...@michelf.com wrote:
Personally, I think it'd be much cleaner
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
On 2012-05-29 13:29:35 +, Don Clugston d...@nospam.com said:
On 27/05/12 02:45, Walter Bright wrote:
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
On 05/29/12 16:20, Michel Fortin wrote:
On 2012-05-29 13:29:35 +, Don Clugston d...@nospam.com said:
On 27/05/12 02:45, Walter Bright wrote:
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
On 2012-05-29 15:09:00 +, Artur Skawina art.08...@gmail.com said:
int a[1024];
int[] da = a[0..1024];
if (whatever)
da = da[3..14];
if (something_else)
da = [42] ~ da;
// etc
if (da_is_a_slice_of_a())
still_inside_a();
How do you implement
On Tuesday, 29 May 2012 at 17:35:12 UTC, Michel Fortin wrote:
On 2012-05-29 15:09:00 +, Artur Skawina
art.08...@gmail.com said:
int a[1024];
int[] da = a[0..1024];
if (whatever)
da = da[3..14];
if (something_else)
da = [42] ~ da;
// etc
if (da_is_a_slice_of_a())
On 5/29/2012 6:29 AM, Don Clugston wrote:
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
On 5/29/2012 7:20 AM, Michel Fortin wrote:
Wouldn't it be possible to just catch the case where you compare two pointers
not assigned from the same memory block and issue an error?
Here's an idea: make each CTFE pointer some kind of struct with a pointer to the
memory block and an offset. When
Just a general note: going the make a special case for two
comparisons route won't work if, for example, someone decides to
use a lambda for comparing pointers.
On 05/27/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
On 26.05.2012 05:35, Walter Bright wrote:
On 5/25/2012 8:24 PM, Don wrote:
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
Le 25/05/2012 17:38, Steven Schveighoffer a écrit :
On Fri, 25 May 2012 11:08:52 -0400, David Nadlinger s...@klickverbot.at
wrote:
On Friday, 25 May 2012 at 14:06:55 UTC, Steven Schveighoffer wrote:
Remove the restriction. The code is unpredictable, but not invalid.
It just means you need to
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
The current implementation of CTFE strictly enforces C pointer
semantics. One of the restrictions is that you cannot perform ordering
comparisons between unrelated pointers.
This is important for repeatability: if it was permitted, the results
would be arbitrary and might vary unpredictably
On 05/25/12 08:50, Don Clugston wrote:
The current implementation of CTFE strictly enforces C pointer semantics. One
of the restrictions is that you cannot perform ordering comparisons between
unrelated pointers.
This is important for repeatability: if it was permitted, the results would
On 25.05.2012 10:50, Don Clugston wrote:
The current implementation of CTFE strictly enforces C pointer
semantics. One of the restrictions is that you cannot perform ordering
comparisons between unrelated pointers.
This is important for repeatability: if it was permitted, the results
would be
On Fri, 25 May 2012 02:50:21 -0400, Don Clugston d...@nospam.com wrote:
The current implementation of CTFE strictly enforces C pointer
semantics. One of the restrictions is that you cannot perform ordering
comparisons between unrelated pointers.
This is important for repeatability: if it was
On Friday, 25 May 2012 at 14:06:55 UTC, Steven Schveighoffer
wrote:
Remove the restriction. The code is unpredictable, but not
invalid. It just means you need to take more care when writing
such code.
The question is whether we want to allow unpredictable behavior
at compile time.
David
On Fri, 25 May 2012 11:08:52 -0400, David Nadlinger s...@klickverbot.at
wrote:
On Friday, 25 May 2012 at 14:06:55 UTC, Steven Schveighoffer wrote:
Remove the restriction. The code is unpredictable, but not invalid.
It just means you need to take more care when writing such code.
The
I think repeatability of CTFE is much important.
If it is not guaranteed, debugging codes for CTFE is almost impossible.
I hate such special treatments.
And, with CTFEable copy operation, overlapping check is always same as
unrelated memory comparison.
For bug 7898, we should add __ctfe specific
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
On Friday, 25 May 2012 at 06:50:22 UTC, Don Clugston wrote:
This is important for repeatability: if it was permitted, the
results would be arbitrary and might vary unpredictably with
subtle changes in the code, or change between compiler releases.
Wait, what?
Pointer semantics are
On 26.05.2012 03:39, Mehrdad wrote:
On Friday, 25 May 2012 at 06:50:22 UTC, Don Clugston wrote:
This is important for repeatability: if it was permitted, the results
would be arbitrary and might vary unpredictably with subtle changes in
the code, or change between compiler releases.
Wait,
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.
On 5/25/2012 8:24 PM, Don wrote:
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
30 matches
Mail list logo
