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 really big
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
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
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 Sat, 16 Aug 2014 17:49:28 +
Kagamin via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
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. ;-)
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
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
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.
Pass
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
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 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
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
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
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
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
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
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
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
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
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
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 down
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
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,
On Fri, 15 Aug 2014 20:19:18 +
Carl Sturtivant via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com 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 --
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
where
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.
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 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
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
format DMD
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 debugger should I
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
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 where to start
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
/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
proper StackOverflowException somehow
(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 seems to
have been fixed. Feel free to create a new
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,
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
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 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
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
. 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
Fine. But nothing of them explain the Stack overflow if i add an
additional method or disable/add an additional ctor.
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.
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
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
My fault, Ref!(Foo) rf = new Foo(); work as expected.
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?
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*
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
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
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
));
[/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
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
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
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
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
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
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.
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 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
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
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 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. ;)
So here i proudly present my Ref struct (2.0 ;))
http://dpaste.dzfl.pl/905e1d3d
So, any suggestions, further ideas or criticism?
BTW: Any tries to declare
@disable
this(typeof(null)); end with the same message 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
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
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
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
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
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:
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
On Fri, 22 Jun 2012 15:55:12 +0100, Namespace rswhi...@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
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
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
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
Hm, doesn't anybody know anything about it?
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 comes from recursive calls which fills the stack? Is that a bug
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 the bug
fix come with 2.060?
With this functionality, the NotNull
...
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?
Yes.
I found nothing
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 comes from recursive calls which fills the stack
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 NotNull. The Output is Stack
overflow. I
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, but I'll
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 this be related to how WinXP managers error reporting
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 crash
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
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)();
---
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)();
---
Like
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 temp = fact!(X - 1
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 temp = fact!(X
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,
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
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,
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 ;-)
95 matches
Mail list logo
