as D lacks the delphi extern 'foo.dll'
I've written (and now with 0.56 it works). a dynamic loading module.
the example on how to use loads the winmm.dll and allows you to use
timeBeginPeriod, etc.

hope someone else finds this useful.

there are some problems with templates that I've got to checkout, and it would be good if there was a better way to write the templates.

Mike.

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:b33mmg$3fr$1@digitaldaemon.com...
> as D lacks the delphi extern 'foo.dll'
> I've written (and now with 0.56 it works). a dynamic loading module.
> the example on how to use loads the winmm.dll and allows you to use
> timeBeginPeriod, etc.
>
> hope someone else finds this useful.
>
> there are some problems with templates that I've got to checkout, and it would be good if there was a better way to write the templates.

Let's pin down why things are going wrong with the templates - the other reports posted about templates were bugs in my implementation, the concept was still sound.

> >
> > there are some problems with templates that I've got to checkout, and it would be good if there was a better way to write the templates.
>
> Let's pin down why things are going wrong with the templates - the other reports posted about templates were bugs in my implementation, the concept was still sound.
>
I meant problems with the template mainly due to my programming, or way I'm
trying to use them.
I think all the bugs that I managed to encounter have been posted.

I posted this as I find it useful, and am not that experianced with
templates, I use them in C++ a little not done any hardcore c++ for a year
or two, (even them I made little use of templating) most of the code I
written on the past 2 years has been Java, C or Delphi.
so I was curious if there was a better way to achieve the same results.
some of the 'problems' I encountered which are  highlighted in this code
are;

no way to create param list template types so there is fixed number of
params that can be used in a dynamic func.
however allowing a param list in a template would also require internal
(rather than external) specilization, a switch
on how many params or ever their type (like a case in record in
pascal/delphi) which means in many cases the current
methods for templating are fine as there are very few cases when a param
list within a template would not be used as
anything more than a param list (no trying to access actual values etc).

void as a type requires a specialisation
template foo(T) {
    T func() { return T.init; }
}

instance foo( void ) bar; // no allowed :( no return allowed from void func

templates have their own linkage (which is good ... but not for this code)
so again I had too cheat and create a Linkage enum and then specialise.
somthing like
template( char[] L, T ) {
    extern( L ) { T func() { return t.init; }
}
might be nice.

these problems are not new, for instance the c++
http://sourceforge.net/projects/sigslot/
library also have a lot of reuse of the same code to solve similar problems
(or should I say lack of syntax)

this is not a critisism of D templates (I like templates, although see them as usefull for library code more than app code) just an observation on problem I ran into, and a question to see if someone can think up a better solution without resorting to requests for templates as params to templates or template that inherit from templates. (mmm templated templates that sounds like the classic "any problem can be solved by adding another level of indirection" :)

Mike.

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:b370l3$abu$1@digitaldaemon.com...
> no way to create param list template types so there is fixed number of
> params that can be used in a dynamic func.
> however allowing a param list in a template would also require internal
> (rather than external) specilization, a switch
> on how many params or ever their type (like a case in record in
> pascal/delphi) which means in many cases the current
> methods for templating are fine as there are very few cases when a param
> list within a template would not be used as
> anything more than a param list (no trying to access actual values etc).

I'm lost with that.

> void as a type requires a specialisation
> template foo(T) {
>     T func() { return T.init; }
> }
> instance foo( void ) bar; // no allowed :( no return allowed from void
func

That can be fixed.

> templates have their own linkage (which is good ... but not for this code)
> so again I had too cheat and create a Linkage enum and then specialise.
> somthing like
> template( char[] L, T ) {
>     extern( L ) { T func() { return t.init; }
> }
> might be nice.

I never thought of that.

"Walter" <walter@digitalmars.com> wrote in message news:b38icr$1m93$1@digitaldaemon.com...
>
> "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:b370l3$abu$1@digitaldaemon.com...
> > no way to create param list template types so there is fixed number of
> > params that can be used in a dynamic func.
> > however allowing a param list in a template would also require internal
> > (rather than external) specilization, a switch
> > on how many params or ever their type (like a case in record in
> > pascal/delphi) which means in many cases the current
> > methods for templating are fine as there are very few cases when a param
> > list within a template would not be used as
> > anything more than a param list (no trying to access actual values etc).
>
> I'm lost with that.
>
consider;
template one( R ) { alias R (*fp)(); }
template one( R, P ) { alias R (*fp)(P); }
template one( R, P0, P1 ) { alias R (*fp)(P0, P1); }
is bounded to allow more params a new template has to be delcared
as I see it any scheme to allow varargs templates would only benifit a small
class of templates (i.e. the dyn loader lib I wrote and maybe sig/slot style
libs).

template one( R, P[] ) { alias R (*fp)(P); }

template one( R, P[] ) { alias R (*fp)(P);
    class foo { abstract R evoke( P ); }
    R func( foo f, P ) { return f.evoke( P ); }
 }

however this might be useful for my dynamic loading template where none of the template params are used or above were the params are passed to something else directly (sigslot lib is similar).

but a can forsee that you might require processing P[0] etc differently if their types differ

template one( R, P[] ) { alias R (*fp)(P);
    class foo { abstract R evoke( P ); }
    select( P[0] ) {
    case : int =  R func( foo f, P ) { return cast(R)(new Integer(
f.evoke( P ) )); }
    case : void = R func( foo f, P[1..] ) { return f.evoke( P[1..] ); }
    case : default  = R func( foo f, P ) { return f.evoke( P ); }
 }

this is just the same as

template one( R, P0 : int, P[] ) { alias R (*fp)(P0, P);
    class foo { abstract R evoke( P ); }
    R func( foo f, P ) { return f.evoke( P ); }
 }
template one( R, P0 : void, P[] ) { alias R (*fp)(P0, P);
    class foo { abstract R evoke( P ); }
    R func( foo f, P ) { return f.evoke( P ); }
 }
template one( R, P0, P[] ) { alias R (*fp)(P0, P);
    class foo { abstract R evoke( P ); }
    R func( foo f, P ) { return f.evoke( P ); }
 }

it would be good not to have to cut'n'paste so much, (hence the sugestion of templates inheriting from templates although how that works in reality I've no idea and think it would all end in tears )

also template matching
template one( R, B[], I : int, P[] )

one( float, long, long, int, float, float ) -> R:float, B[long, long],
I:int, P[float, float]
one( float, int, int, int, float ) !! whjat does this match why how and it
is worth the effort ?

so I conclude its a feature that solves one problem but creates a load more.