1) inner class cannot new itself:

class A {
B newB() {return new B();}
class B {
B dup() {
B r;
r = newB();  // workaround
r = new B(); // error out: inner.d(7): no 'this' for nested class B
return r;
}
}
}

I understand the reason, and I know the workaround; but can we make it legal, by just copying the 'this' pointer (should be called 'outer' really) from the invoking object?  So writing innerClass.dup will be much easier.


2) generate runtime error-out in debug mode when a float value NaN is evaluated.

The propagation property of NaN as init value of float is great: whenever NaN is used as an operand, the result is NaN.  The only problem is the programmer still need to trace back the computation path to determine the locate of the bug.

I wonder if the compiler can help on this: in debug mode, whenever a NaN is evaluated, generate a runtime error straight away.  So the programmer can immediate identify the bug location.

In article <dg74l5$1q57$1@digitaldaemon.com>, z@gg.com says...
>
>1) inner class cannot new itself:
>
>class A {
>B newB() {return new B();}
>class B {
>B dup() {
>B r;
>r = newB();  // workaround
>r = new B(); // error out: inner.d(7): no 'this' for nested class B
>return r;
>}
>}
>}
>
>I understand the reason, and I know the workaround; but can we make it legal, by just copying the 'this' pointer (should be called 'outer' really) from the invoking object?  So writing innerClass.dup will be much easier.

I don't understand.  Why is a 'this' pointer to B required in order to construct a new instance of B?  Or perhaps you left a 'this' out of the example?

# class A {
#     class B {
#         B dup() { return new B(this); }
#     }
# }

In this case, that the code doesn't work seems entirely reasonable.

>2) generate runtime error-out in debug mode when a float value NaN is evaluated.

Interesting idea.  Is there any way to accomplish this in hardware?  It would stink having the compiler insert evaluations after every floating-point operation.


Sean

>>I understand the reason, and I know the workaround; but can we make it legal, by just copying the 'this' pointer (should be called 'outer' really) from the invoking object?  So writing innerClass.dup will be much easier.
>
>I don't understand.  Why is a 'this' pointer to B required in order to construct a new instance of B?

It's non-static inner-class, which contains a hidden 'this' pointer (should be called 'outer' really) to the enclosing object.

Right now D's nested class have the same semantics as in Java, check "What's New for D 0.126", and also  http://digitalmars.com/d/class.html#nested


>Interesting idea.  Is there any way to accomplish this in hardware?  It would stink having the compiler insert evaluations after every floating-point operation.

It would be great if this can be caught by setting up some hardware traps.  Even if this cannot be done by hardware, I think it will still help the programmer a lot by software simulation.  Maybe another flag (e.g. "-NaN") can be introduced to let the programmer explicitly enable this behaviour.  It may runs slow, but you will identify the bug straight away.

In article <dg7d1c$23mi$1@digitaldaemon.com>, z@gg.com says...
>
>>>I understand the reason, and I know the workaround; but can we make it legal, by just copying the 'this' pointer (should be called 'outer' really) from the invoking object?  So writing innerClass.dup will be much easier.
>>
>>I don't understand.  Why is a 'this' pointer to B required in order to construct a new instance of B?
>
>It's non-static inner-class, which contains a hidden 'this' pointer (should be called 'outer' really) to the enclosing object.

Understood.  But shouldn't this only be an issue when access to B's internal data is necessary?  Constructing a new instance of B is more akin to calling a function than to accessing data.


Sean

idea:
"() ? (A) : (B) = rvalue;" is legal, if A and B are legal lvalues.

sample code:
	int a = 3;
	int b = 7;

	((a > b) ? (a) : (b)) = a*b + (b << 1) - (a >> 1) * (a & b);

reason:
Limit code duplication and use of temporary variables in order to reduce
the bug-proneness of complex evaluations.


As far as I am aware there are no side effects for existing code.

On Wed, 14 Sep 2005 01:07:00 +0200, Thomas Kühne wrote:

> idea:
> "() ? (A) : (B) = rvalue;" is legal, if A and B are legal lvalues.
> 
> sample code:
> 	int a = 3;
> 	int b = 7;
> 
> 	((a > b) ? (a) : (b)) = a*b + (b << 1) - (a >> 1) * (a & b);
> 
> reason:
> Limit code duplication and use of temporary variables in order to reduce
> the bug-proneness of complex evaluations.
> 
> As far as I am aware there are no side effects for existing code.

I haven't got any idea about what you are trying to do. It is not obvious to me at all. Can you rewrite your example using the long method so I can see the logic flow etc....


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
14/09/2005 10:03:04 AM

"Derek Parnell" <derek@psych.ward> wrote in message news:12zsfnc0t7lua.1wbg7upo8ws6s$.dlg@40tude.net...
> I haven't got any idea about what you are trying to do. It is not obvious to me at all. Can you rewrite your example using the long method so I can see the logic flow etc....

This:

(a < b) ? (a) : (b) = 15;

Would be the same as:

if(a < b)
    a = 15;
else
    b = 15;

So it's using the ?: to select the destination of the assignment instead of the source.

On Tue, 13 Sep 2005 20:08:02 -0400, Jarrett Billingsley wrote:

> "Derek Parnell" <derek@psych.ward> wrote in message news:12zsfnc0t7lua.1wbg7upo8ws6s$.dlg@40tude.net...
>> I haven't got any idea about what you are trying to do. It is not obvious to me at all. Can you rewrite your example using the long method so I can see the logic flow etc....
> 
> This:
> 
> (a < b) ? (a) : (b) = 15;
> 
> Would be the same as:
> 
> if(a < b)
>     a = 15;
> else
>     b = 15;
> 
> So it's using the ?: to select the destination of the assignment instead of the source.

Okay, so the general form would be ...

  (BooleanExpression) ? (Identifier1) : (Identifier2) = Expression;

which would be equivalent to  ...

   { // Start a scoping block.
     Typeof(Expression) Temp = Expression;
     if (BooleanExpression == true)
       Identifier1 = Temp;
     else
       Identifier2 = Temp;
   }

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
14/09/2005 10:11:09 AM

z@gg.com wrote:
>>>I understand the reason, and I know the workaround; but can we make it legal, by
>>>just copying the 'this' pointer (should be called 'outer' really) from the
>>>invoking object?  So writing innerClass.dup will be much easier.
>>
>>I don't understand.  Why is a 'this' pointer to B required in order to
>>construct a new instance of B?
> 
> 
> It's non-static inner-class, which contains a hidden 'this' pointer (should be
> called 'outer' really) to the enclosing object.
> 
> Right now D's nested class have the same semantics as in Java, check "What's New
> for D 0.126", and also  http://digitalmars.com/d/class.html#nested
> 
> 
> 
>>Interesting idea.  Is there any way to accomplish this in hardware?  It would
>>stink having the compiler insert evaluations after every floating-point
>>operation.
> 
> 
> It would be great if this can be caught by setting up some hardware traps.  Even
> if this cannot be done by hardware, I think it will still help the programmer a
> lot by software simulation.  Maybe another flag (e.g. "-NaN") can be introduced
> to let the programmer explicitly enable this behaviour.  It may runs slow, but
> you will identify the bug straight away.
> 

The hardware does trap such cases.  It's called a signalling (or noisy) NaN.  Most NaNs, however, are quiet NaNs.  D's float.nan is a quiet NaN, which does not signal when evaluated.  I'm not an expert on the IEEE floating point spec by any means.

I'm also not quite sure how the signal from the FPU gets to the CPU to the application... I believe on Linux it is achieved with a SIGFPE signal sent to the app, which must trap it and handle it accordingly. I'm not sure how easy or difficult it would be to achieve the same effect using exceptions.

In article <dg80p3$2m8s$1@digitaldaemon.com>, James Dunne says...
>
>The hardware does trap such cases.  It's called a signalling (or noisy) NaN.  Most NaNs, however, are quiet NaNs.  D's float.nan is a quiet NaN, which does not signal when evaluated.  I'm not an expert on the IEEE floating point spec by any means.
>
>I'm also not quite sure how the signal from the FPU gets to the CPU to the application... I believe on Linux it is achieved with a SIGFPE signal sent to the app, which must trap it and handle it accordingly. I'm not sure how easy or difficult it would be to achieve the same effect using exceptions.

SIGFPE is a standard C signal so it should work on Windows as well.  Now that I think about it, std.c.fenv has functions to specify floating-point behavior, though I've never actually used them.  There's a copy of a D header here:

http://svn.dsource.org/projects/ares/trunk/src/ares/std/c/fenv.d


Sean