www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Stack overflow

reply "Namespace" <rswhite4 googlemail.com> writes:
I have this code:
http://codepad.org/vz17iZrm

And as long as i comment out the assert's in the constructor on 
line 10 and the assert in the invariant on line 16 it works as i 
want.
But otherwise the compiler prints stackoverflow and that's all.

Why and how is the stack overflowed with an simple assert?!
Jun 22 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 22-06-2012 12:22, Namespace wrote:

 I have this code:
 http://codepad.org/vz17iZrm

 And as long as i comment out the assert's in the constructor on line 10
 and the assert in the invariant on line 16 it works as i want.
 But otherwise the compiler prints stackoverflow and that's all.

 Why and how is the stack overflowed with an simple assert?!


Wow, you really managed to dig up some compiler bugs here.

OK, so first of all, if you change the asserts to assert(obj); and 
assert(_obj); (I assume this is what you meant in the invariant), the 
code compiles. This is clearly a bug.

Now, if you change the first assert to assert(obj); and the one in the 
invariant to assert(obj); *too* (invalid code), the compiler just plain 
seg faults.

The workaround, as mentioned, is to either use assert(obj); and 
assert(_obj); or assert(!!obj); and assert(!!_obj);. The reason the 
latter forms may be desirable is that the former calls obj's invariant 
in addition to checking for null. The latter doesn't.

In any case, please file bugs for these issues. You really managed to 
run into some unusually broken parts of the compiler, it seems. :-/

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Jun 22 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/22/2012 12:22 PM, Namespace wrote:

 I have this code:
 http://codepad.org/vz17iZrm

 And as long as i comment out the assert's in the constructor on line 10
 and the assert in the invariant on line 16 it works as i want.
 But otherwise the compiler prints stackoverflow and that's all.

 Why and how is the stack overflowed with an simple assert?!


On my machine it is the compiler that crashes => compiler bug.
Presumably it is having trouble with the circular alias this.
(BTW, what is 'obj' in the invariant supposed to refer to?)
Jun 22 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
 On my machine it is the compiler that crashes => compiler bug.
 Presumably it is having trouble with the circular alias this.


My first try to avoid this "circular" bug work with opDispatch. 
(As you can read here on my blog: 
http://blog.rswhite.de/archives/741)
Now i had a new idea to save the Reference and call only these, 
it seems that it works fine and with a lot less code.


 (BTW, what is 'obj' in the invariant supposed to refer to?)


Just for testing. ;)

 Alex Rønne Petersen:
Thanks a lot, i use assert(obj); that seems to serve the purpose.
I hope in the next version "alias this" is more stable.
Jun 22 2012
parent reply David <d dav1d.de> writes:
Am 22.06.2012 12:52, schrieb Namespace:

 On my machine it is the compiler that crashes => compiler bug.
 Presumably it is having trouble with the circular alias this.


 My first try to avoid this "circular" bug work with opDispatch. (As you
 can read here on my blog: http://blog.rswhite.de/archives/741)
 Now i had a new idea to save the Reference and call only these, it seems
 that it works fine and with a lot less code.


 (BTW, what is 'obj' in the invariant supposed to refer to?)


 Just for testing. ;)

  Alex Rønne Petersen:
 Thanks a lot, i use assert(obj); that seems to serve the purpose.
 I hope in the next version "alias this" is more stable.


I am wondering why you wanna have Objects which will never be null. Use 
a contract which checks for null and you're done (another benefit, it 
get's removed if you compile with -release).

The only thing you gain from that is an Exception instead of a Segfault, 
where is the benefit, the app crashes in both cases and if you wanna 
handle those Exceptions, you can also check for null which is definitly 
faster and more readable (because it's clear to everyone).

There were a few discussion about adding a NullPointerException, 
personally I wouldn't care if there was one, but implementing this 
behaviour with a library is the wrong way imo. This spreads 
inconsistency over D, some use it others don't, beginners will be confused.

Btw. when developing, just start your program always with a debugger 
(shift+F9 instead of F9 for me, not a big deal), it will halt on a 
segfault and you can check why there is one.
Jun 22 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
If you have a null object you get an Access Violation without 
_any_ further information. That totally sucks.
And in my opinion a small "Ref!Type" is more informative for 
others who use your code and you do not have to write assert(obj 
!is null); any time in any method again.

And yes my program start's first with a debugger but, as i said, 
you will only get "Access Violation" and must debug by yourself 
to find the null object, if you avoid assert's.
Jun 22 2012
next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Fri, 22 Jun 2012 15:55:12 +0100, Namespace <rswhite4 googlemail.com>  
wrote:


 If you have a null object you get an Access Violation without _any_  
 further information. That totally sucks.


It doesn't have to be that way.

A debug executable contains all sort of debugging information and a Just  
In Time debugger can attach and make use of it to show the cause of the  
access violation.  Further, on both windows and various flavours of unix  
you can get a stack dump, which can be loaded into a debugger and used to  
locate the access violation.

For the JIT case it's all automated on windows if/when you have visual  
studio installed, as soon as any application crashes a dialog appears and  
you can attach/debug.

For the stack trace case I prefer using WinDbg where you can load the  
stack trace, point it at the PDB (produced even on a release build) and  
figure out where it crashed.  If you have no PDB you can use a MAP file  
and the stack offsets to determine the crash location.

Alternately, on windows you can call SetUnhandledExceptionFilter() to  
install a handler to catch any/all unhandled "exceptions" including access  
violations etc and then using the EXCEPTION_POINTERS ContextRecord member,  
walk the stack and produce your own stack trace at the instant the  
application "crashes" - I have some code which does this somewhere..

This last idea could automatically be built into exes produced by DMD so  
they all crash and output a stack trace (perhaps only if built in debug  
mode) and something similar can surely be done for unix.  It's been a  
while since I did any serious development in D so maybe automatic stack  
traces already happen for some platforms?


 And in my opinion a small "Ref!Type" is more informative for others who  
 use your code and you do not have to write assert(obj !is null); any  
 time in any method again.


It is nice to perform the assert/check once, then know from that point on  
it cannot be null ever again - saves multiple asserts/checks and makes the  
code cleaner in terms of having less "noise".  I think types which cannot  
be null are useful for that reason.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Jun 22 2012
prev sibling parent reply David <d dav1d.de> writes:
Am 22.06.2012 16:55, schrieb Namespace:

 If you have a null object you get an Access Violation without _any_
 further information. That totally sucks.


I don't know what you're doing or which debugger you use, gdb shows me 
exactly what happened (line + stack + object).


 And in my opinion a small "Ref!Type" is more informative for others who
 use your code and you do not have to write assert(obj !is null); any
 time in any method again.


I hope nobody will share code with Ref!Type, if they do people will 
relay on it and hey, all will do it, I don't need to check here, would 
be something different if it was not implemented by any library.


 And yes my program start's first with a debugger but, as i said, you
 will only get "Access Violation" and must debug by yourself to find the
 null object, if you avoid assert's.


I have to debug nothing, as written above gdb sets automatically a 
breakpoint on a segmentation fault and shows me all the information I need.
Jun 22 2012
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, June 22, 2012 19:59:48 David wrote:

 Am 22.06.2012 16:55, schrieb Namespace:

 If you have a null object you get an Access Violation without _any_
 further information. That totally sucks.


 
 I don't know what you're doing or which debugger you use, gdb shows me
 exactly what happened (line + stack + object).


Well, he's clearly on Windows if he's seeing an access violation, but 
regardless, there are plenty of developers who have no clue that you can get 
any information from a segfault or access violation. Personally, I'd been 
programming in C/C++ for years before I found out it was possible. And it can 
be _very_ frustrating to get a segfault when all that tells you is that you're 
programming is crashing somewhere, somehow.

Fortunately, debuggers like gdb make it possible to figure out what happened in 
great detail (either by examining a core dump or running the program in a 
debugger), but my guess is that Namespace just doesn't know how to do that or 
that it's even possible - hence his frustration with not getting any 
information.

- Jonathan M Davis
Jun 22 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
 debugger), but my guess is that Namespace just doesn't know how 
 to do that or
 that it's even possible - hence his frustration with not 
 getting any
 information.


Exactly.

And I use VisualD and the standard debugger of it.
Jun 22 2012
parent reply David <d dav1d.de> writes:
Am 22.06.2012 23:11, schrieb Namespace:

 debugger), but my guess is that Namespace just doesn't know how to do
 that or
 that it's even possible - hence his frustration with not getting any
 information.


 Exactly.

 And I use VisualD and the standard debugger of it.


Sorry but I would learn how to use the debugger instead (it helps a 
lot!), instead of implementing features which emulate C++ behaviour 
(according to your blog) and will confuse people, e.g. if you 
documentate that, people will be like *huh this cannot be null, is this 
a feature I don't know?* and end up confused.
Jun 22 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Friday, 22 June 2012 at 23:01:47 UTC, David wrote:

 Am 22.06.2012 23:11, schrieb Namespace:

 debugger), but my guess is that Namespace just doesn't know 
 how to do
 that or
 that it's even possible - hence his frustration with not 
 getting any
 information.


 Exactly.

 And I use VisualD and the standard debugger of it.


 Sorry but I would learn how to use the debugger instead (it 
 helps a lot!), instead of implementing features which emulate 
 C++ behaviour (according to your blog) and will confuse people, 
 e.g. if you documentate that, people will be like *huh this 
 cannot be null, is this a feature I don't know?* and end up 
 confused.


I would prefer NullPointer Exceptions and / or not null types 
rather than playing around with the debugger.
That's the first step.
Jun 22 2012
next sibling parent reply David <d dav1d.de> writes:
Am 23.06.2012 07:27, schrieb Namespace:

 I would prefer NullPointer Exceptions and / or not null types rather
 than playing around with the debugger.
 That's the first step.


Yeah but not implemented by a library.
Jun 23 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Saturday, 23 June 2012 at 09:53:35 UTC, David wrote:

 Am 23.06.2012 07:27, schrieb Namespace:

 I would prefer NullPointer Exceptions and / or not null types 
 rather
 than playing around with the debugger.
 That's the first step.


 Yeah but not implemented by a library.


Not yet. ;)
Jun 23 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
So here i proudly present my Ref struct (2.0 ;))
http://dpaste.dzfl.pl/905e1d3d

So, any suggestions, further ideas or criticism?
Jun 23 2012
parent "Namespace" <rswhite4 googlemail.com> writes:
BTW: Any tries to declare
 disable
this(typeof(null)); end with the same message "Stack overflow"...
Jun 23 2012
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, June 23, 2012 07:27:56 Namespace wrote:

 I would prefer NullPointer Exceptions and / or not null types
 rather than playing around with the debugger.
 That's the first step.


NullPointerExceptions (well, they'd end up being NullPointersErrors) will 
_never_ happen. Walter is completely against them. From his point of view, the 
OS is _already_ checking this for you (hence the segfault or access 
violation), so there's no point in having the language check.

We might end up with something in druntime which prints out a stacktrace when 
a segfault occurs, but that's the closest that you'll ever get to a null 
pointer exception in D.

A non-nullable type _will_ be added to Phobos at some point. The issue is a 
matter of implementation. At least one has been submitted, but it wasn't good 
enough to be included as it stood. So, it hasn't been merged in. As soon as 
there is one which is good enough and has been appropriately reviewed by the 
Phobos devs, we'll have one. But until then, we don't.

- Jonathan M Davis
Jun 23 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
 A non-nullable type _will_ be added to Phobos at some point.


As struct or class or as built-in type?

And can me explain somebody why
[code]
 disable
this(typeof(null));
[/code]
print "Stack overflow"?
Jun 24 2012
next sibling parent reply David <d dav1d.de> writes:
Am 24.06.2012 11:35, schrieb Namespace:

 A non-nullable type _will_ be added to Phobos at some point.


 As struct or class or as built-in type?

 And can me explain somebody why
 [code]
  disable
 this(typeof(null));
 [/code]
 print "Stack overflow"?



What should typeof(null) return you? void*, int*
Jun 24 2012
next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Sunday, 24 June 2012 at 10:37:39 UTC, David wrote:

 Am 24.06.2012 11:35, schrieb Namespace:

 A non-nullable type _will_ be added to Phobos at some point.


 As struct or class or as built-in type?

 And can me explain somebody why
 [code]
  disable
 this(typeof(null));
 [/code]
 print "Stack overflow"?



 What should typeof(null) return you? void*, int*


I don't understand, what do you mean?
Jun 24 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/24/2012 12:37 PM, David wrote:

 Am 24.06.2012 11:35, schrieb Namespace:

 A non-nullable type _will_ be added to Phobos at some point.


 As struct or class or as built-in type?

 And can me explain somebody why
 [code]
  disable
 this(typeof(null));
 [/code]
 print "Stack overflow"?



 What should typeof(null) return you? void*, int*


typeof(null) gives typeof(null).
Jun 24 2012
parent David <d dav1d.de> writes:
Am 24.06.2012 13:15, schrieb Timon Gehr:

 On 06/24/2012 12:37 PM, David wrote:

 Am 24.06.2012 11:35, schrieb Namespace:

 A non-nullable type _will_ be added to Phobos at some point.


 As struct or class or as built-in type?

 And can me explain somebody why
 [code]
  disable
 this(typeof(null));
 [/code]
 print "Stack overflow"?



 What should typeof(null) return you? void*, int*


 typeof(null) gives typeof(null).


Right my bad, I was confused a bit
Jun 24 2012
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 24, 2012 11:35:46 Namespace wrote:

 A non-nullable type _will_ be added to Phobos at some point.


 
 As struct or class or as built-in type?


As I said, it will be added to _Phobos_. So, it will be a struct in the 
standard library, not in the language itself. It'll probably be NonNullable!T.

- Jonathan M Davis
Jun 24 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Sunday, 24 June 2012 at 11:55:15 UTC, Jonathan M Davis wrote:

 On Sunday, June 24, 2012 11:35:46 Namespace wrote:

 A non-nullable type _will_ be added to Phobos at some point.


 
 As struct or class or as built-in type?


 As I said, it will be added to _Phobos_. So, it will be a 
 struct in the
 standard library, not in the language itself. It'll probably be 
 NonNullable!T.

 - Jonathan M Davis


You can take my Ref struct. ;)
And can me now anybody explain why
 disable
this(typeof(null)); or any other ctor declaration prints "stack 
overflow"?
How it is possible, that one class and one struct kill the stack?
Jun 24 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 24, 2012 14:09:38 Namespace wrote:

 And can me now anybody explain why
  disable
 this(typeof(null)); or any other ctor declaration prints "stack
 overflow"?
 How it is possible, that one class and one struct kill the stack?


Please provide a compilable example which exhibits the problem so that we can 
see exactly what you're talking about and reproduce it.

- Jonathan M Davis
Jun 24 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Sunday, 24 June 2012 at 12:19:47 UTC, Jonathan M Davis wrote:

 On Sunday, June 24, 2012 14:09:38 Namespace wrote:

 And can me now anybody explain why
  disable
 this(typeof(null)); or any other ctor declaration prints "stack
 overflow"?
 How it is possible, that one class and one struct kill the 
 stack?


 Please provide a compilable example which exhibits the problem 
 so that we can
 see exactly what you're talking about and reproduce it.

 - Jonathan M Davis


http://dpaste.dzfl.pl/ca77bc96

Comment out "alias this" in Foo or " disable this(typeof(null));" 
in Test solve the problem. Otherwise it prints "Stack overflow".
Jun 24 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 24, 2012 14:29:10 Namespace wrote:

 On Sunday, 24 June 2012 at 12:19:47 UTC, Jonathan M Davis wrote:

 On Sunday, June 24, 2012 14:09:38 Namespace wrote:

 And can me now anybody explain why
  disable
 this(typeof(null)); or any other ctor declaration prints "stack
 overflow"?
 How it is possible, that one class and one struct kill the
 stack?


 
 Please provide a compilable example which exhibits the problem
 so that we can
 see exactly what you're talking about and reproduce it.
 
 - Jonathan M Davis


 
 http://dpaste.dzfl.pl/ca77bc96
 
 Comment out "alias this" in Foo or " disable this(typeof(null));"
 in Test solve the problem. Otherwise it prints "Stack overflow".


My guess is that you've got something recursive going on (possibly a recursive 
template instantiation, though I don't see any reason why that would occur), 
which causes it to eat up more and more memory, until the OS kills it.

Report it as a dmd bug: http://d.puremagic.com

- Jonathan M Davis
Jun 24 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
 My guess is that you've got something recursive going on 
 (possibly a recursive
 template instantiation, though I don't see any reason why that 
 would occur),
 which causes it to eat up more and more memory, until the OS 
 kills it.

 Report it as a dmd bug: http://d.puremagic.com

 - Jonathan M Davis


All right, but have you any workaround?
As long as it endures to fix a bug in dmd, i'm a old men when i 
can work with it.
Jun 24 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 24, 2012 14:57:37 Namespace wrote:

 My guess is that you've got something recursive going on
 (possibly a recursive
 template instantiation, though I don't see any reason why that
 would occur),
 which causes it to eat up more and more memory, until the OS
 kills it.
 
 Report it as a dmd bug: http://d.puremagic.com
 
 - Jonathan M Davis


 
 All right, but have you any workaround?
 As long as it endures to fix a bug in dmd, i'm a old men when i
 can work with it.


This might work:

this(U)(U obj)
    if(is(U : T) && !is(U == typeof(null)))
{
}


- Jonathan M Davis
Jun 24 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
 This might work:

 this(U)(U obj)
     if(is(U : T) && !is(U == typeof(null)))
 {
 }


 - Jonathan M Davis


Interesting. With or wihtout that, if i add a method to Foo it 
prints "Stack overflow" also.

http://dpaste.dzfl.pl/91dad66c

Can you explain that?
Jun 24 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 24, 2012 19:03:17 Namespace wrote:

 This might work:
 
 this(U)(U obj)
 
     if(is(U : T) && !is(U == typeof(null)))
 
 {
 }
 
 
 - Jonathan M Davis


 
 Interesting. With or wihtout that, if i add a method to Foo it
 prints "Stack overflow" also.
 
 http://dpaste.dzfl.pl/91dad66c
 
 Can you explain that?


Wait, you have a template mixin inside of Foo which passes Foo to it? I don't 
know if you can get away with that or not, since you're trying to pass a type 
to a template while you're adding stuff to it via that template. So, the type 
is incomplete. I'm willing to be that that's your problem, but I don't know.

- Jonathan M Davis
Jun 24 2012
next sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
 Wait, you have a template mixin inside of Foo which passes Foo 
 to it? I don't
 know if you can get away with that or not, since you're trying 
 to pass a type
 to a template while you're adding stuff to it via that 
 template. So, the type
 is incomplete. I'm willing to be that that's your problem, but 
 I don't know.

 - Jonathan M Davis


If so, the problem would have to solved if i switch from a mixin 
to an abstract class. Or not?
Or have you any other idea?
Jun 24 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, June 25, 2012 08:24:59 Namespace wrote:

 Wait, you have a template mixin inside of Foo which passes Foo
 to it? I don't
 know if you can get away with that or not, since you're trying
 to pass a type
 to a template while you're adding stuff to it via that
 template. So, the type
 is incomplete. I'm willing to be that that's your problem, but
 I don't know.
 
 - Jonathan M Davis


 
 If so, the problem would have to solved if i switch from a mixin
 to an abstract class. Or not?
 Or have you any other idea?


If you don't need to use any compile-time reflection on the type itself (i.e. 
you just need its name), you can use a string mixin.

- Jonathan M Davis
Jun 25 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
 If you don't need to use any compile-time reflection on the 
 type itself (i.e.
 you just need its name), you can use a string mixin.

 - Jonathan M Davis


You mean i should pack the whole mixin template in a string?
Isn't that a little bit ugly?
Jun 25 2012
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, June 25, 2012 10:18:19 Namespace wrote:

 If you don't need to use any compile-time reflection on the
 type itself (i.e.
 you just need its name), you can use a string mixin.
 
 - Jonathan M Davis


 
 You mean i should pack the whole mixin template in a string?
 Isn't that a little bit ugly?


More or less yeah. You generate the code as a string and then mix it in. As 
it's a string, it's really easy to manipulate, and if you lay out the strings 
properly, it's not really even particularly hard to read. Personally, I never 
use template mixins, and I get the impression that string mixins get used a 
lot more than template mixins do.

- Jonathan M Davis
Jun 25 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/25/2012 02:48 AM, Jonathan M Davis wrote:

 On Sunday, June 24, 2012 19:03:17 Namespace wrote:

 This might work:

 this(U)(U obj)

      if(is(U : T)&&  !is(U == typeof(null)))

 {
 }


 - Jonathan M Davis


 Interesting. With or wihtout that, if i add a method to Foo it
 prints "Stack overflow" also.

 http://dpaste.dzfl.pl/91dad66c

 Can you explain that?


 Wait, you have a template mixin inside of Foo which passes Foo to it? I don't
 know if you can get away with that or not, since you're trying to pass a type
 to a template while you're adding stuff to it via that template. So, the type
 is incomplete. I'm willing to be that that's your problem, but I don't know.

 - Jonathan M Davis


This is fine. I am doing it all the time.
Why are we discussing this compiler bug on the main newsgroup though?
Jun 25 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, June 25, 2012 13:01:47 Timon Gehr wrote:

 On 06/25/2012 02:48 AM, Jonathan M Davis wrote:

 On Sunday, June 24, 2012 19:03:17 Namespace wrote:

 This might work:
 
 this(U)(U obj)
 
      if(is(U : T)&&  !is(U == typeof(null)))
 
 {
 }
 
 
 - Jonathan M Davis


 
 Interesting. With or wihtout that, if i add a method to Foo it
 prints "Stack overflow" also.
 
 http://dpaste.dzfl.pl/91dad66c
 
 Can you explain that?


 
 Wait, you have a template mixin inside of Foo which passes Foo to it? I
 don't know if you can get away with that or not, since you're trying to
 pass a type to a template while you're adding stuff to it via that
 template. So, the type is incomplete. I'm willing to be that that's your
 problem, but I don't know.
 
 - Jonathan M Davis


 
 This is fine. I am doing it all the time.


If it works, then it works, but it surprises me a bit, given that you can't do 
that with template declarations normally.


 Why are we discussing this compiler bug on the main newsgroup though?


We're not discussing this on the main newsgroup. This is d-learn.

- Jonathan M Davis
Jun 25 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
Fine. But nothing of them explain the Stack overflow if i add an 
additional method or disable/add an additional ctor.
Jun 25 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/25/2012 02:18 PM, Namespace wrote:

 Fine. But nothing of them explain the Stack overflow if i add an
 additional method or disable/add an additional ctor.


It does not have to be explained: it is a compiler bug.
Jun 25 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Monday, 25 June 2012 at 15:39:19 UTC, Timon Gehr wrote:

 On 06/25/2012 02:18 PM, Namespace wrote:

 Fine. But nothing of them explain the Stack overflow if i add 
 an
 additional method or disable/add an additional ctor.


 It does not have to be explained: it is a compiler bug.


Then it will take months or years until it is fixed ... too bad.

And that Ref!(Foo) rf = new Foo(); ends even with "Stack 
overflow" and Ref!(Foo) rf2 = new Ref!(Foo)(new Foo()); not has 
the same explanation "Compiler Bug", hm?
Jun 25 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/25/2012 05:52 PM, Namespace wrote:

 On Monday, 25 June 2012 at 15:39:19 UTC, Timon Gehr wrote:

 On 06/25/2012 02:18 PM, Namespace wrote:

 Fine. But nothing of them explain the Stack overflow if i add an
 additional method or disable/add an additional ctor.


 It does not have to be explained: it is a compiler bug.


 Then it will take months or years until it is fixed ... too bad.


Many of them get fixed quite fast if they are reported properly.


 And that Ref!(Foo) rf = new Foo(); ends even with "Stack overflow" and
 Ref!(Foo) rf2 = new Ref!(Foo)(new Foo()); not has the same explanation
 "Compiler Bug", hm?


It is always a compiler bug if compilation crashes.
Jun 25 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
 Many of them get fixed quite fast if they are reported properly.


But since I have had other experiences. But no matter.


 It is always a compiler bug if compilation crashes.


Only that a simple " disable this(typeof(null));" fails, is crap. 
Because so you cannot test at compile time for such assignments.
Jun 25 2012
parent "Namespace" <rswhite4 googlemail.com> writes:
My fault, Ref!(Foo) rf = new Foo(); work as expected.
Jun 25 2012