• Dario (75/75) Mar 10 2003 _____THOUGHT 1_____
• Walter (5/5) Mar 18 2003 You're right about making function and delegates the same thing. I've

"Dario" <supdar yahoo.com> writes:

_____THOUGHT 1_____
The implementation of closures in D is simply fantastic. It makes us able to
pass any sort of function pointers to other functions. Anyway the
distinction between function pointers and delegates is a hindrance and we
should think of a workaround.
I think that it should be legal to cast a function pointer into a delegate.
This would be possible if 'this' were the first argument to be pushed in the
stack (when calling a class (or closure) member). (I don't know if this is
how it actually works.) This way, when we call a delegate, 'this' wouldn't
be read by the function.
For example:
{
    static int callback() {return 0;}
    int delegate() fp = cast(int delegate()) &callback;
}
Or simply
{
    int delegate() fp = function int() {return 0;};
}
A delegate is a couple of a class address (or a stack frame address) and a
function pointer. The address is pushed into the stack within the other
arguments (if there are any), then the function is called.
If the function doesn't expect the address to be pushed, it won't crash if
it's pushed before the arguments.

I remember that it was asked what calling convention D uses. It was replied
that it wasn't specified in the language specifications so that the compiler
would be able to choose the best one. Anyway I wonder how it can be possible
since the language lets us call function pointers: it has to call them
without knowing the calling conventions in advance. So D should have a
calling convention and maybe it's better to specify it in the specs.

_____THOUGHT 2_____
(I saw a discussion about DLLs somewhere but I don't remember in which
thread it is, so I write here.)
I am not a professional programmer; I program only in my free time because I
enjoy it. Thus I have never written very complex programs and I have never
needed dynamic libraries.
But even if I have very little experience I feel that DLLs are very useful
when programs become really complex.
I once tried to learn how to write them, but even if I succeeded I found
them too cumbersome to write. I think that D should have a neater way to
make them.

Actually we have to write a function called DLLEntryPoint or DLLMain whose
function is to initialize the GC and to tag every function we want to export
with the "export" statement.
IMO we should be able transform a module into a DLL without planning it or
writing the module with this intent. Then a compiler switch should make it
compile a DLL instead of an EXE.
For example:
__________
module mydll;
// a DLLEntryPoint which initialize the GC should be spontaneously generated
by the compiler
int b;
static this()
{
    b = 6;
    // the static constructor of a DLL should be called by DLLEntryPoint
}
public:
// every public function is exported in the DLL
void blah()
{}
__________
module dllcaller;
import mydll;
int main()
{
    blah();
}

This should be compiler using these two commands:
dmd -dll mydll.d <- this makes mydll.lib and mydll.dll
dmd dllcaller.d mydll.lib <- this makes dllcaller.d which loads mydll.dll
and calls its function

I thank you for your patience and attention. I apologise for my English:
it's not as straightforward as D! ;-)

"Walter" <walter digitalmars.com> writes:

You're right about making function and delegates the same thing. I've
thought of a way to do it, but it will take some implementation effort and
hence some time.

The DLL idea is more problematic. I don't think you'll ever be able to
really get away from all the idiosyncracies of making DLLs.