Walter:
Keep in mind that it is IMPOSSIBLE for any static analyzer to prove there are
no order dependencies when the order is implementation defined.
I see.
D's approach on this allows one to reason reliably about how the code works -
this does NOT contribute to making code unreadable.
The back end will evaluate them in different orders, as it is
more efficient to evaluate varargs functions from
right-to-left, and others from left-to-right. It's not an
insurmountable problem, it just needs to be worked on.
Are you taking about push vs mov? By default gcc preallocates
space
On 12/17/2011 2:04 AM, Kagamin wrote:
The back end will evaluate them in different orders, as it is more efficient
to evaluate varargs functions from right-to-left, and others from
left-to-right. It's not an insurmountable problem, it just needs to be worked
on.
Are you taking about push vs
Walter:
x = x++;
Define order of evaluation as rvalue, then lvalue.
So I presume your desire is to define the semantics of all code like that, and
statically refuse no cases like that. This is an acceptable solution.
The advantage of this solution is that it gives no restrictions on the
On 12/17/2011 2:54 AM, bearophile wrote:
Walter:
x = x++;
Define order of evaluation as rvalue, then lvalue.
So I presume your desire is to define the semantics of all code like that,
and statically refuse no cases like that. This is an acceptable solution.
The advantage of this solution
There are the videos of the 2011 LLVM Developer Meeting:
http://www.youtube.com/playlist?list=PL970A5BD02C11F80C
Slides too:
http://llvm.org/devmtg/2011-11/
As usual the LLVM talks are quite interesting. I have started to see the
videos/slides, it will require some time.
An interesting talk,
On Friday, 16 December 2011 at 12:23:25 UTC, bearophile wrote:
This code doesn't compile with DMD:
if (x = y) {}
But this gives no errors:
if (x |= y) {}
Do you know why DMD forbids assignments as conditions, but it
accepts compound assignments there? It looks like a
incongruence that's
On 16-12-2011 13:23, bearophile wrote:
There are the videos of the 2011 LLVM Developer Meeting:
http://www.youtube.com/playlist?list=PL970A5BD02C11F80C
Slides too:
http://llvm.org/devmtg/2011-11/
As usual the LLVM talks are quite interesting. I have started to see the
videos/slides, it will
Adam D. Ruppe:
But I've never myself, nor seen anybody else, actually
write += or |= when they meant == or !=. The keys aren't
even close (on en-US anyway) so it's not a likely typo, and
the concepts are nothing alike so a brain or language mixup
isn't likely to cause it.
If you write
On 12/16/2011 06:50 PM, Walter Bright wrote:
D2 intends to define the order of evaluation of function arguments as
strictly left-to-right. There are some problems implementing this, but
that's where we want to go with it.
What would be a case where this currently does not hold?
On 12/16/2011 4:23 AM, bearophile wrote:
This code doesn't compile with DMD:
Error: assignment cannot be used as a condition, perhaps == was meant?
void main() {
int x, y;
if (x = y) {}
}
But this gives no errors:
void main() {
int x, y;
if (x |= y) {}
if (x += y) {}
Walter:
Given the frequence of bugs caused by the ?: operator, I think something
like this will be good to have in D too.
I haven't seen the bug every time with this.
Surely it's not a bug every time (but maybe was often enough a bug in the
Chromium project, that is several millions
On 12/16/2011 9:52 AM, Timon Gehr wrote:
On 12/16/2011 06:50 PM, Walter Bright wrote:
D2 intends to define the order of evaluation of function arguments as
strictly left-to-right. There are some problems implementing this, but
that's where we want to go with it.
What would be a case where
On 12/16/2011 10:16 AM, bearophile wrote:
There is also the problem of code like this, that will require one or more
solutions for D2. Defining or refusing or this kind of code are the
possibilities (or both of such solutions, in different situations):
x = x++;
Define order of evaluation as
On 12/16/2011 10:43 AM, Walter Bright wrote:
x = x++;
Define order of evaluation as rvalue, then lvalue.
Which, I might add, is a tractable problem. Trying to nail down every case of
OOE dependencies is flat out impossible.
On 12/16/2011 07:45 PM, Walter Bright wrote:
On 12/16/2011 10:43 AM, Walter Bright wrote:
x = x++;
Define order of evaluation as rvalue, then lvalue.
Which, I might add, is a tractable problem. Trying to nail down every
case of OOE dependencies is flat out impossible.
How can that work
On 12/16/2011 10:58 AM, Timon Gehr wrote:
Which, I might add, is a tractable problem. Trying to nail down every
case of OOE dependencies is flat out impossible.
How can that work together with NRVO?
These are orthogonal.
17 matches
Mail list logo
