www.digitalmars.com         C & C++   DMDScript  

D - Dynamic function loading module

reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
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.
Feb 20 2003
parent reply "Walter" <walter digitalmars.com> writes:
"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.
Feb 21 2003
parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
 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.

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.
Feb 21 2003
parent reply "Walter" <walter digitalmars.com> writes:
"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

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.
Feb 22 2003
parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"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.

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.
Feb 22 2003