[C] Winapi Call Dynamically and easily

[mcp]

Which is what you want, unless performance is your top priority (likely isn't). You simply have to make sure to invoke FreeLibrary accordingly. That's why I subsequently proposed to make the actual call through a functor which would invoke FreeLibrary in the destructor.

[bugficks]

youre mixing stuff up. that GetModuleHandle/LoadLibrary is from original post and thats C, functor in C w/ destructor?
my c++14 version keeps lib ref count constant, thats the sole purpose of the map (what you call 'cache')
also you want to keep lib loaded as dlls might have some init/deinit functions or keep some state between calls.

so if you want to fix version from original post use GetModuleHandleEx and call FreeLibrary later only if GetModuleHandleEx returned a valid handle.
for my c++ version just use thread_local on map like i ve already said before. this will also fix if a dll uses DLL_THREAD_ATTACH which a mutex does not.

[mcp]

I was referring to the ref count problem: that can be trivially solved by having correct pairing of Load/FreeLibrary (and doing what i proposed earlier with a functor would do the right thing). I do not see how that is solved with the c++14 approach you posted? How are LoadLibrary / FreeLibrary calls matched without leaking library handles?

edit: ah got it, it's the shared pointer that points a custom deleter to FreeLibrary. ok. However, for all practical purposes this just keeps libraries loaded until the thread exits - which may or may not be what you want - you have no control over it.

edit2: to clarify, the functor approach was suggested because it inherently avoids unnecessary API lookups, e.g., if you invoke an API in a loop, you'll do the same lookup over and over again because you have coupled lookup with invocation of the API. The functor approach however decouples lookup from invoking, is thread-safe by definition and doesn't need any synchronization mechanisms.

[bugficks]

w/ thread_local its a per thread map and lib is loaded/freed per thread, if that thread exits is see no problem there. OS lib ref count is the same as it was before thread was entered.

well again, this was just a c++ type safe replacement for original post, nothing more nothing less. if you want to do an uber lib loader youre free to do so

if you want to optimize lookup you could as well just add an optional opaque pointer and store some infos there.
e.g.:

PHP Code:

template <typename F, typename... ArgTypes>
auto DynCallT(void **opaque, LPCTSTR libName, LPCSTR funcName, ArgTypes... args)
{ 
    if(opaque && *opaque) 
    { (cast_opaque_t)(opaque) ...} 
    ... 
    if(opaque) 
    { *opaque=... }
    ...
}
void *ppp=0;
for(...) DynCallT(ppp, ...); 


anyways, it is what it is and it doesnt want to be more

[aliali]

Originally Posted by bugficks

w/ thread_local its a per thread map and lib is loaded/freed per thread, if that thread exits is see no problem there. OS lib ref count is the same as it was before thread was entered.

well again, this was just a c++ type safe replacement for original post, nothing more nothing less. if you want to do an uber lib loader youre free to do so

if you want to optimize lookup you could as well just add an optional opaque pointer and store some infos there.
e.g.:

PHP Code:

template <typename F, typename... ArgTypes>
auto DynCallT(void **opaque, LPCTSTR libName, LPCSTR funcName, ArgTypes... args)
{ 
    if(opaque && *opaque) 
    { (cast_opaque_t)(opaque) ...} 
    ... 
    if(opaque) 
    { *opaque=... }
    ...
}
void *ppp=0;
for(...) DynCallT(ppp, ...); 


anyways, it is what it is and it doesnt want to be more

Is it possible to have a pure ANSI C implementation of the above code

[0xall0c]

Originally Posted by aliali

Is it possible to have a pure ANSI C implementation of the above code

not possible, as i know, but there can be work around at lower levels