Prev: ImageList + extract image
Next: calculating process size from map file
From: ScottMcP [MVP] on 10 Feb 2010 13:18
On Feb 10, 3:36 am, glitteringsounds <muhammadusman.kha...(a)gmail.com>
wrote:
> Respectfully Sir!!
>
> My goal to call every exported function of DLL without need to declare
> function pointers.If DLL contains 100 funcs(exported methods) having
> different types(i.e their return type and in/out params) I need 100
> function pointers. Every time GetProcAddress needs to be type casted
> with those 100 func pointers. Creates horrible maintainaince
> nightmare. Every time new function included, you need pointer of that
> type to be declare in code.

Yes, with GetProcAddress you need to declare 100 function pointers.
The maintenance nightmare is caused by using explicit linking
(GetProcAddress). If you use implicit linking the nightmare is gone!


>
> Wot about delegates..?
>
> Delegate usage prevents user to use GetProcAddress and require any
> function pointer to work with.
> It wraps all functions to which you want to call at run time. Thus
> we'll not need any function pointer or need to know the type for that
> pointer.

Delegates do need to know the parameters ("function signature").


From: glitteringsounds on 11 Feb 2010 02:16
On Feb 11, 12:44 am, David Given <d...(a)cowlark.com> wrote:
> On 10/02/10 08:34, glitteringsounds wrote:
> [...]
>
> > My goal to call every exported function of DLL without need to declare
> > function pointers.If DLL contains 100 funcs(exported methods) having
> > different types(i.e their return type and in/out params) I need 100
> > function pointers. Every time GetProcAddress needs to be type casted
> > with those 100 func pointers. Creates horrible maintainaince
> > nightmare. Every time new function included, you need pointer of that
> > type to be declare in code.
>
> That is correct. You do need to do that. There's no way round it.
>
> You need to have a correctly typed function pointer because otherwise
> the compiler doesn't know how to pass parameters correctly. Consider:
>
> void foo(int32_t x, int32_t y);
> void bar(int64_t x, int32_t y);
>
> When you call foo(), the compiler will push two quads onto the stack (x
> and y). When you call bar(), the compiler will push *three* quads onto
> the stack (low half of x, high half of x, and y).
>
> If you call foo() using a pointer to a bar() function, the compiler will
> push three quads when calling the function, but the function itself will
> only pop two quads --- and so the parameters will get horribly mangled.
>
> It gets even worse when you start dealing with __stdcall vs __ccall.
> *shudder*
>
> [...]
>
> > Delegate usage prevents user to use GetProcAddress and require any
> > function pointer to work with.
> > It wraps all functions to which you want to call at run time. Thus
> > we'll not need any function pointer or need to know the type for that
> > pointer.
>
> Yes --- *but* the delegate code will still need to know the types of the
> parameters in order to work correctly. It's precisely the same problem,
> except now you're doing it at run time instead of compile time.
> You may find it easier to do this, as it might be easier to manage the
> information using a big run-time table of function signatures rather
> than using source code, but still can't get away from the real problem.
>
> (Bear in mind that delegates are much, much slower than direct function
> calls.)
>
> --
> ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────http://www.cowlark.com─────
> │
> │ 𝕻𝖍'𝖓𝖌𝖑𝖚𝖎 𝖒𝖌𝖑𝖜'𝖓𝖆𝖋𝖍 𝕮𝖙𝖍𝖚𝖑𝖍𝖚 𝕽'𝖑𝖞𝖊𝖍
> 𝖜𝖌𝖆𝖍'𝖓𝖆𝖌𝖑 𝖋𝖍𝖙𝖆𝖌𝖓.
> │
No any other way to solve the problem except delegates.
I've googled about runtime delegates that generates function calls to
functions appropriately. 'MethodInfo', 'ParameterInfo' of Reflections
will do the job using 'object' as param types of delegates.
Any suggestions or reccomendations still..? As delegates are slow and
when working on 100's of functions will definely make the app slower
to run.
First  |  Prev  | 
Pages: 1 2
Prev: ImageList + extract image
Next: calculating process size from map file