On 08/15/2014 05:09 PM, Sean Kelly wrote:
At least on OSX, it appears that mapping memory is constant time
regardless of size, but there is some max total memory I'm allowed to
map, presumably based on the size of a vmm lookup tabe. The max block
size I can allocate is 1 GB, and I can allocate r
Am I missing something? Is there a clean and simple way to get Fiber to
no longer suffer a stack overflow when implementing D-routines?
Simply choose a big enough stack size when creating your fibers.
http://dlang.org/library/core/thread/Fiber.this.html
It's fairly cheap to use a reall
On Friday, 15 August 2014 at 15:50:30 UTC, Dicebot wrote:
On Friday, 15 August 2014 at 15:40:35 UTC, Sean Kelly wrote:
On Friday, 15 August 2014 at 15:25:23 UTC, Dicebot wrote:
No, I was referring to the proposal to supply bigger stack
size to Fiber constructor - AFAIR it currently does alloc
On Sat, 16 Aug 2014 17:49:28 +
Kagamin via Digitalmars-d-learn
wrote:
> You should only choose stack size carefully or keep data in
> TempAlloc instead of stack.
but i can choose stack size carefully without such 'address reserving'
feature. ;-)
signature.asc
Description: PGP signature
On Friday, 15 August 2014 at 22:26:54 UTC, ketmar via
Digitalmars-d-learn wrote:
and we -- 32-bit addicts -- will run out of address space while
64-bit
happy people will laugh looking at us. ;-)
You should only choose stack size carefully or keep data in
TempAlloc instead of stack.
On Fri, 15 Aug 2014 20:19:18 +
Carl Sturtivant via Digitalmars-d-learn
wrote:
> Should have read further down the thread --- you're right as the
> memory is in effect merely reserved virtual memory and isn't
> actually allocated.
and we -- 32-bit addicts -- will run out of address space whi
On Friday, 15 August 2014 at 20:17:51 UTC, Carl Sturtivant wrote:
On Friday, 15 August 2014 at 15:40:35 UTC, Sean Kelly wrote:
I thought it did, but apparently the behavior of VirtualAlloc
and mmap (which Fiber uses to allocate the stack) simply
reserves the range and then commits it lazily,
shows that a
Fiber suffers a stack overflow that doesn't lead to a clean
termination when this limit is exceeded.
Pass a bigger stack size to the Fiber constructor?
No good if the stack size needed depends dynamically on the
computation in that Fiber.
Should have read further dow
On Friday, 15 August 2014 at 15:40:35 UTC, Sean Kelly wrote:
On Friday, 15 August 2014 at 15:25:23 UTC, Dicebot wrote:
No, I was referring to the proposal to supply bigger stack
size to Fiber constructor - AFAIR it currently does allocate
that memory eagerly (and does not use any OS CoW tools
On Friday, 15 August 2014 at 08:41:30 UTC, Kagamin wrote:
On Thursday, 14 August 2014 at 07:46:29 UTC, Carl Sturtivant
wrote:
The default size of the runtime stack for a Fiber is
4*PAGESIZE which is very small, and a quick test shows that a
Fiber suffers a stack overflow that doesn't lead
On Thursday, 14 August 2014 at 18:52:00 UTC, Sean Kelly wrote:
On 64 bit, reserve a huge chunk of memory, set a SEGV handler
and commit more as needed. Basically how kernel thread stacks
work. I've been meaning to do this but haven't gotten around to
it yet.
Very nice; the hardware VM machine
On Friday, 15 August 2014 at 15:40:35 UTC, Sean Kelly wrote:
On Friday, 15 August 2014 at 15:25:23 UTC, Dicebot wrote:
No, I was referring to the proposal to supply bigger stack
size to Fiber constructor - AFAIR it currently does allocate
that memory eagerly (and does not use any OS CoW tools
On Friday, 15 August 2014 at 15:25:23 UTC, Dicebot wrote:
No, I was referring to the proposal to supply bigger stack size
to Fiber constructor - AFAIR it currently does allocate that
memory eagerly (and does not use any OS CoW tools), doesn't it?
I thought it did, but apparently the behavior
On Friday, 15 August 2014 at 14:45:02 UTC, Sean Kelly wrote:
On Friday, 15 August 2014 at 14:28:34 UTC, Dicebot wrote:
Won't that kind of kill the purpose of Fiber as low-cost
context abstraction? Stack size does add up for thousands of
fibers.
As long as allocation speed is fast for large
At least on OSX, it appears that mapping memory is constant time
regardless of size, but there is some max total memory I'm
allowed to map, presumably based on the size of a vmm lookup
tabe. The max block size I can allocate is 1 GB, and I can
allocate roughly 131,000 of these blocks before ge
On Friday, 15 August 2014 at 14:28:34 UTC, Dicebot wrote:
Won't that kind of kill the purpose of Fiber as low-cost
context abstraction? Stack size does add up for thousands of
fibers.
I didn't measure it.
On Friday, 15 August 2014 at 14:26:28 UTC, Sean Kelly wrote:
On Friday, 15 August 2014 at 08:36:34 UTC, Kagamin wrote:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887%28v=vs.85%29.aspx
Allocates memory charges (from the overall size of memory and
the paging files on disk) for t
On Friday, 15 August 2014 at 14:28:34 UTC, Dicebot wrote:
Won't that kind of kill the purpose of Fiber as low-cost
context abstraction? Stack size does add up for thousands of
fibers.
As long as allocation speed is fast for large allocs (which I
have to test), I want to change the default s
On Friday, 15 August 2014 at 14:28:34 UTC, Kagamin wrote:
On Friday, 15 August 2014 at 14:26:28 UTC, Sean Kelly wrote:
Oh handy, so there's basically no work to be done on Windows.
I'll have to check the behavior of mmap on Posix.
I heard, calloc behaves this way on linux (COW blank page
map
On Friday, 15 August 2014 at 14:26:28 UTC, Sean Kelly wrote:
Oh handy, so there's basically no work to be done on Windows.
I'll have to check the behavior of mmap on Posix.
I heard, calloc behaves this way on linux (COW blank page mapped
to the entire range), it was discussed here some time a
On Friday, 15 August 2014 at 08:41:30 UTC, Kagamin wrote:
On Thursday, 14 August 2014 at 07:46:29 UTC, Carl Sturtivant
wrote:
The default size of the runtime stack for a Fiber is
4*PAGESIZE which is very small, and a quick test shows that a
Fiber suffers a stack overflow that doesn't lead
On Friday, 15 August 2014 at 08:36:34 UTC, Kagamin wrote:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887%28v=vs.85%29.aspx
Allocates memory charges (from the overall size of memory and
the paging files on disk) for the specified reserved memory
pages. The function also guarant
On Thursday, 14 August 2014 at 07:46:29 UTC, Carl Sturtivant
wrote:
The default size of the runtime stack for a Fiber is 4*PAGESIZE
which is very small, and a quick test shows that a Fiber
suffers a stack overflow that doesn't lead to a clean
termination when this limit is exceeded.
P
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887%28v=vs.85%29.aspx
Allocates memory charges (from the overall size of memory and
the paging files on disk) for the specified reserved memory
pages. The function also guarantees that when the caller later
initially accesses the memo
On Thursday, 14 August 2014 at 18:52:00 UTC, Sean Kelly wrote:
On 64 bit, reserve a huge chunk of memory, set a SEGV handler
and commit more as needed. Basically how kernel thread stacks
work. I've been meaning to do this but haven't gotten around to
it yet.
AFAIK, OS already provides this tr
On Thursday, 14 August 2014 at 18:52:00 UTC, Sean Kelly wrote:
On 64 bit, reserve a huge chunk of memory, set a SEGV handler
and commit more as needed. Basically how kernel thread stacks
work. I've been meaning to do this but haven't gotten around to
it yet.
I think using some sort of thread-
On Thursday, 14 August 2014 at 07:46:29 UTC, Carl Sturtivant
wrote:
The default size of the runtime stack for a Fiber is 4*PAGESIZE
which is very small, and a quick test shows that a Fiber
suffers a stack overflow that doesn't lead to a clean
termination when this limit is exceeded.
On 64 bit, reserve a huge chunk of memory, set a SEGV handler and
commit more as needed. Basically how kernel thread stacks work.
I've been meaning to do this but haven't gotten around to it yet.
but not that i can think of.
On Thursday, 14 August 2014 at 07:46:29 UTC, Carl Sturtivant
wrote:
The default size of the runtime stack for a Fiber is 4*PAGESIZE
which is very small, and a quick test shows that a Fiber
suffers a stack overflow that doesn't lead to a clean
terminatio
The default size of the runtime stack for a Fiber is 4*PAGESIZE
which is very small, and a quick test shows that a Fiber suffers
a stack overflow that doesn't lead to a clean termination when
this limit is exceeded.
This makes it difficult to simulate deterministic alternation
wher
On 2013-12-30 23:21, Vladimir Panteleev wrote:
You could try reducing the bug using DustMite, and this helper:
Thanks, DustMite was able to find a reduced test case. It was this
little piece of code:
enum : DWORD
{
DWORD = REG_DWORD
}
--
/Jacob Carlborg
On Monday, 30 December 2013 at 13:04:38 UTC, Jacob Carlborg wrote:
I've ported one of my projects[1] from D1 to D2 and it works
perfectly fine on Posix. Now when I try to compile the code on
Windows I get a stack overflow. I really suck at Windows
development, I don't even know wher
On 2013-12-30 17:19, Benjamin Thaut wrote:
Compile in 64-bit and use Visual Studio or Visual Studio Express to
debug the application. If you want to compile in 32-bit you will need to
run cv2pdb on the generated exectuable before debugging with visual
studio. cv2pdb is part of VisualD which I re
Am 30.12.2013 14:04, schrieb Jacob Carlborg:
I've ported one of my projects[1] from D1 to D2 and it works perfectly
fine on Posix. Now when I try to compile the code on Windows I get a
stack overflow. I really suck at Windows development, I don't even know
where to start. Which debugge
I've ported one of my projects[1] from D1 to D2 and it works perfectly
fine on Posix. Now when I try to compile the code on Windows I get a
stack overflow. I really suck at Windows development, I don't even know
where to start. Which debugger should I use that can handle the debug
inedocs/gcc-4.1.2/gnat_ugn_unw/Stack-Overflow-Checking.html
>
> Thank you,
> bye,
> bearophile
I'm not opposed. It is easily possible to segfault an @safe
D program with a stack overflow. E.g. not cautious when writing
the exit condition in a recursive function. If this can be a
pro
ull(this);", in the
"_convert" method of NotNull. The Output is "Stack
overflow". I think
that comes from recursive calls which fills the stack? Is
that a bug?
Yes.
I found nothing like that. Is the bug reported?
I remember reporting a similar issue, but that one
My fault, Ref!(Foo) rf = new Foo(); work as expected.
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 a
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
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
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.
Fine. But nothing of them explain the Stack overflow if i add an
additional method or disable/add an additional ctor.
>>
> >>> 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 &q
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 "S
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 tha
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?
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,
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
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.
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?
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 i
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
hat 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&quo
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 struc
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 compilab
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
));
[/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
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
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"?
W
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 ove
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*
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"?
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 complet
BTW: Any tries to declare
@disable
this(typeof(null)); end with the same message "Stack overflow"...
So here i proudly present my Ref struct (2.0 ;))
http://dpaste.dzfl.pl/905e1d3d
So, any suggestions, further ideas or criticism?
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. ;)
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.
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 s
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 ha
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 smal
On Fri, 22 Jun 2012 15:55:12 +0100, Namespace
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
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
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/
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 R
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 h
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
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 simp
I'd like to open an enhancement request for something like this
as a feature for all D compilers, what do you think? (Generally
Ada has something to teach to D design):
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gnat_ugn_unw/Stack-Overflow-Checking.html
Thank you,
bye,
bearophile
On Tuesday, 24 April 2012 at 19:34:26 UTC, Timon Gehr wrote:
On 04/24/2012 07:09 PM, Namespace wrote:
...
And therefore i get the same error, as if i wrote "return
NotNull!(Foo)(this);" instead of "return
assumeNotNull(this);", in the
"_convert" method of
On 04/24/2012 07:09 PM, Namespace wrote:
...
And therefore i get the same error, as if i wrote "return
NotNull!(Foo)(this);" instead of "return assumeNotNull(this);", in the
"_convert" method of NotNull. The Output is "Stack overflow". I think
that co
...
And therefore i get the same error, as if i wrote "return
NotNull!(Foo)(this);" instead of "return
assumeNotNull(this);", in the
"_convert" method of NotNull. The Output is "Stack overflow".
I think
that comes from recursive calls which fills the s
his);" instead of "return
assumeNotNull(this);", in the
"_convert" method of NotNull. The Output is "Stack overflow".
I think
that comes from recursive calls which fills the stack? Is that
a bug?
Yes.
Some ideas how i can implement this otherwise? And would
instead of the two
declarations you have.
...
And therefore i get the same error, as if i wrote "return
NotNull!(Foo)(this);" instead of "return assumeNotNull(this);", in the
"_convert" method of NotNull. The Output is "Stack overflow". I think
that come
Hm, doesn't anybody know anything about it?
void main() {
}
And therefore i get the same error, as if i wrote "return
NotNull!(Foo)(this);" instead of "return assumeNotNull(this);",
in the "_convert" method of NotNull. The Output is "Stack
overflow". I think that comes from recursive calls which fills
the stack? Is that a bug?
Andrej Mitrovic:
> I'm fairly sure this used to give me a stack overflow error:
It's a regression:
http://d.puremagic.com/issues/show_bug.cgi?id=6088
Bye,
bearophile
On Friday, October 07, 2011 05:28:39 Andrej Mitrovic wrote:
> I'm fairly sure this used to give me a stack overflow error:
> void test() {
> test();
> }
>
> void main() {
> test();
> }
>
> Now it only returns exit code -1073741819.
>
> Could th
I'm fairly sure this used to give me a stack overflow error:
void test() {
test();
}
void main() {
test();
}
Now it only returns exit code -1073741819.
Could this be related to how WinXP managers error reporting? It's
possible that I have some error reporting service disabled
This crashes at runtime because of a stack overflow, without stack frame or
error message (DMD 2.053), no stack trace, or line number are shown:
int foo(int n) {
return n ? foo(n - 1) : 1;
}
void main() {
foo(100_000);
}
If you aren't running a debugger then receiving a nude cra
Ary Borenszweig:
> Thanks. Later in my head I instantiated the template and noticed the
> problem.
In time I have created similar problems in my code 2-3 times, missing a
"static" before some "if".
Can't the compiler help spot such bugs? If the variables a dynamic if works on
are constants (exp
Moritz Warning escribió:
On Sun, 24 May 2009 20:49:53 -0300, Ary Borenszweig wrote:
When I compile this code I get "stack overflow" printed in the console.
Anyone know why?
---
int fact(int X)() {
if(X == 0) {
return 1;
} else {
int t
On Sun, 24 May 2009 20:49:53 -0300, Ary Borenszweig wrote:
> When I compile this code I get "stack overflow" printed in the console.
> Anyone know why?
>
> ---
> int fact(int X)() {
> if(X == 0) {
> return 1;
> } else {
>
Ary Borenszweig wrote:
When I compile this code I get "stack overflow" printed in the console.
Anyone know why?
---
int fact(int X)() {
if(X == 0) {
return 1;
} else {
int temp = fact!(X - 1)();
return X * temp;
}
}
const someVar = fact!(0)();
When I compile this code I get "stack overflow" printed in the console.
Anyone know why?
---
int fact(int X)() {
if(X == 0) {
return 1;
} else {
int temp = fact!(X - 1)();
return X * temp;
}
}
const someVar = fact!(0)();
---
Le Sat, 29 Nov 2008 01:49:20 +0100, BCS <[EMAIL PROTECTED]> a écrit:
struct C(R, A...)
{
A args;
R function(A) dg;
static R delegate() opCall(R function(A) dg, A a)
{
C!(R, A) ret;
ret.dg=dg;
foreach(int i,_;A)
ret.args[i] = a[i];
return &ret.fn;
}
R fn()
Reply to TSalm,
Yes, you are right.
But this is an example code. The "true" code uses delegates with
argument
which differs from called functions, so I can't point delegate
directly to
them.
And this anonymous function's way is really fastest to code... I must
waiting for a D2 stable version ;-)
Le Sat, 29 Nov 2008 01:08:28 +0100, BCS <[EMAIL PROTECTED]> a écrit:
Reply to TSalm,
Hello,
I would do something like this, but this return me an execution error
: object.Exception: Stack Overflow
// CODE
class A
{
void delegate() dg;
void doIt()
{
dg();
}
}
class B
Reply to TSalm,
Hello,
I would do something like this, but this return me an execution error
: object.Exception: Stack Overflow
// CODE
class A
{
void delegate() dg;
void doIt()
{
dg();
}
}
class B
{
A a;
this()
{
a = new A;
a.dg = { doSomething(); };
}
void doSomething
Hello,
I would do something like this, but this return me an execution error :
object.Exception: Stack Overflow
// CODE
class A
{
void delegate() dg;
void doIt()
{
dg();
}
}
class B
{
A a;
this()
{
a = new A;
a.dg = { doSomething(); };
}
void doSomething
100 matches
Mail list logo