• Dan <murpsoft hotmail.com> Apr 03 2007
• Kirk McDonald <kirklin.mcdonald gmail.com> Apr 03 2007
• Dan <murpsoft hotmail.com> Apr 03 2007
• Kirk McDonald <kirklin.mcdonald gmail.com> Apr 03 2007
• Chris Nicholson-Sauls <ibisbasenji gmail.com> Apr 03 2007

Dan <murpsoft hotmail.com> writes:

According to the D language spec, a static function:

static int x(int y){
  return 3;
}

is *not* virtual.  Does this mean I can't use:

int function(int y) foo = &x;

???

Or is there something that needs to be changed?  I'm at work now and can't test
it.  : p

Kirk McDonald <kirklin.mcdonald gmail.com> writes:

Dan wrote:
 According to the D language spec, a static function:
 
 static int x(int y){
   return 3;
 }
 
 is *not* virtual.  Does this mean I can't use:
 
 int function(int y) foo = &x;
 
 ???
 
 Or is there something that needs to be changed?  I'm at work now and can't
test it.  : p


No, it means you *can* use that. Static member functions are in essence 
module-level functions that just happen to live inside a class. Pointers 
to static functions are plain old function pointers.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org

Dan <murpsoft hotmail.com> writes:

Kirk McDonald Wrote:
 No, it means you *can* use that. 



The rest didn't make sense.  : p  Classes are still little black boxes to me, I
think well in terms of instructions, pointers, structs and arrays.

So that means I can now go:

static int f1(int x){..}
static int f2(int x){..}
static int f3(int x){..}

static int function(int x)[3] foo = [ &f1, &f2, &f3 ];

???

If that's true, then that will dramatically improve startup performance and
legibility of my Walnut 2.x scripting engine!  : D

Kirk McDonald <kirklin.mcdonald gmail.com> writes:

Dan wrote:
 Kirk McDonald Wrote:
 
No, it means you *can* use that. 


 ...
 
 The rest didn't make sense.  : p  Classes are still little black boxes to me,
I think well in terms of instructions, pointers, structs and arrays.
 
 So that means I can now go:
 
 static int f1(int x){..}
 static int f2(int x){..}
 static int f3(int x){..}
 
 static int function(int x)[3] foo = [ &f1, &f2, &f3 ];
 
 ???
 
 If that's true, then that will dramatically improve startup performance and
legibility of my Walnut 2.x scripting engine!  : D


Note that 'static' at module scope does exactly nothing. There's no 
difference between a static global function and a regular global 
function. (I mentioned classes because, in seeing 'static', I had 
assumed you were talking about classes.)

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org

Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:

Dan wrote:
 Kirk McDonald Wrote:
 No, it means you *can* use that. 


 
 The rest didn't make sense.  : p  Classes are still little black boxes to me,
I think well in terms of instructions, pointers, structs and arrays.
 
 So that means I can now go:
 
 static int f1(int x){..}
 static int f2(int x){..}
 static int f3(int x){..}
 
 static int function(int x)[3] foo = [ &f1, &f2, &f3 ];
 
 ???
 
 If that's true, then that will dramatically improve startup performance and
legibility of my Walnut 2.x scripting engine!  : D


Even better, you can do it like this:

int f1 (int x) {..}
int f2 (int x) {..}
int f3 (int x) {..}

auto foo = [&f1, &f2, &f3];

And replace the 'auto' with 'const' if you want it so...  Except when D's new
const'ness 
concept goes live, then replace it with 'final'... and possibly 'final
invariant' 
depending on your needs.  Man.  I have to admit the transitional period for
that is going 
to be awkward.

-- Chris Nicholson-Sauls