Determining if a function exists

Hi,

I'm currently working on a library/dll, and I'm working if I could do something as follows in the .h of the library/dll:

extern void MyFunc();

and then inside the actual library/dll determine if that function actually exists? I'm wondering this because the way I want this library/dll to work is the user has the option to handle certain things on their own rather then use the default ways and so I was wondering if they could simply make, say... void MyFunc() ...in their program and then voila, the library/dll would then pass it off to MyFunc() to do what has to be done rather then use the defaults? Just one method I was thinking of. Let me know please.

Tyouk

How about something like this?

Code:

---

// funcptr1.c

#include <stdio.h>
#include "funcptr.h"

// Prototype
void myfunc_internal(void);

void (*myfunc)() = myfunc_internal;

void myfunc_internal(void)
{
  puts("This is the default myfunc()");
}

---

Code:

---

// funcptr.h

#ifndef FUNCPTR_H_
#define FUNCPTR_H_

extern void (*myfunc)();

#endif FUNCPTR_H_

---

Code:

---

// funcptr2.c

#include <stdio.h>
#include "funcptr.h"

void myfunc_local(void)
{
  puts("This is the custom myfunc()");
}

int main(void)
{
  myfunc();

  myfunc = myfunc_local;
  myfunc();

  return 0;
}

---

Quote:

---

itsme@dreams:~/C$ ./funcptr
This is the default myfunc()
This is the custom myfunc()
itsme@dreams:~/C$

---

funcptr1.c would actually be your DLL. Is that kind of what you're looking for?

Sort of. Inside the DLL is where I want to know if the function exists or not. Because it's up to the user to create these functions to customize what certain things happen when the DLL is being called upon.

sort of like this inside the DLL file

if( funcExists )
{
myFunc();
}
else
{
// default action
}

so thats what my DLL will try to determine
thanks,
Tyouk

Quote:

---

Originally Posted by tyouk

I'm currently working on a library/dll, and I'm working if I could do something as follows in the .h of the library/dll:

extern void MyFunc();

and then inside the actual library/dll determine if that function actually exists?

---

Do you want DLL "a" to find out if DLL "b" contains function "c()"? You are really unclear as to what you want. That would only make sense if you want to allow the user to use different DLLs with your... uhm, DLL, application or whatever (because otherwise you could just put the available functions in a nice caseblock and select depending on user input).

Assuming this is what you want, why not just declare a function

Code:

---

void *myGetProcAddress(char *func)

---

in every compliant DLL. Passing myGetProcAddress the name of a function will then either return NULL or a valid pointer to that function. Now all you need to know is the parameterlist and return value of it, declare a suitable pointer type for it and ... call it through the pointer.
If the parameterlist is a constant factor in your.... DLL/library... then you might use an appropriate pointer type as return of myGetProcAddress of course.

So then, your code would look like...

Code:

---

if( (myFunc= myGetProcAddress("myFunc")) )
  myFunc();
else {
  // default action
}

---

Well what I'm actually looking for is for my DLL/library to determine if the application it's included in has the function in it. Basically the reason for this is because the user will then have the choice of creating certain functions to handle certain situations in the way they want to handle them. Or they could leave my DLL/library to handle it in the default manner in which it's normally done. Thats why I want to be able to determine if a function exists or not. In the documentation of the DLL/library I will be giving lots of information as well as listings of all functions that they would have to create in order to handle the different situations in the manner in which they want to. So whoever uses this DLL/library will know which functions to create if they want to, but it will be their choice.

I guess I could use the method of using the myGetProcAddress() function mentioned above, but I was hoping to be able to do something more along the lines of just:

in the .h for my DLL/Library

Code:

---

extern int SituationA(char *someChar);

---

and then in the code for the DLL/Library

Code:

---

if SituationA exists
    SituationA(someChar);
else
    // default

---

This way the user doesn't have to do anything extra in order to handle the situation. All they have to do is create a function with the necessary code inside of what they want done for that particular situation. Any ideas on how to do that?

Another method I was contemplating is still placing the "externs" of all the functions into the .h and then having the user pass some sort of value to a function I can create to let me know which ones the user would be handling... such as:

Code:

---

err = UHandle(UH_SITUATIONA | UH_SITUATIONZ...);
if( err == 0 )
        MessageBox(0, "Everything is okay to handle those situations...", "Return Value", MB_OK);
else
        MessageBox(0, "Guess the default is going to be used...", "Return Value", MB_OK);

---

Now I guess no one would want that sort of error handling for theirs, but I just put that in to show how they would know if they could handle those situations or not.

[Edit]
Well I guess I could also use something like what was mentioned above (pointers to the function... declare them as extern int (*SituationA)(); and then point them to the defaults, then if the user wants to handle them, allow them to simply redirect which functions they point to). Thats another way I guess.
[/Edit]

Let me know what you think,
Tyouk

The accepted method to handle this situation is to provide a library function that takes a function pointer. This can be called by the library user if they want to change the default behaviour. A sample in the C library is the signal function. A sample in the WinAPI is SetConsoleCtrlHandler. Most other libraries also use this model.

Even if it was possible, it would not be generally acceptable behaviour* to automatically use a function as a callback. This approach would have several drawbacks:

• The user may want to use a different function or default behaviour depending on run-time conditions.
• The name you select for the callback function may conflict with existing names or naming schemes.
• The user may want to provide the callback function from another DLL.

This being C, it is not too much to demand that the user call a library function to set custom callback functions.

Code:

---

SetCallbackFunction( myCallBackFunction );

---

* Of course, main and some other implementation dependent functions, such as DllMain may be called automatically.

Isn't that pretty much exactly what my code did? You just had to set the function pointer instead of calling a function that set it :)

Well I'm not exactly looking for something that would be a callback. Basically in the DLL/Library, the function would only be called when that situation is met by the run-time conditions as they're met. Thus:

Code:

---

case SituationA
        if SituationA() exists
                SituationA();
        else
                defSituationA();
        break;

---

This way it would be up to the user to choose whether or not to handle that situation. And I do understand what your saying, and I could implement that type of method. But to make it easier on the user I would like to do more of an automated method so then the user just has to create the appropriate function. And trust me, if someone is honestly using the function names that I have so far determined will be used, then I wouldn't have a clue as to what the hell they were thinking for their naming schemes. And if they want to use a function from another DLL/Library then they could use the above mentioned method of making... int (*SituationA)(); ...and point it to the function of another DLL. As for different situations running in their program, thats what if statements are for to determine what exactly has to be done as the programs running. The way I have designed these series of function prototypes, all necessary information will be passed from my DLL/Library to these functions upon call time. So there are no worries there about them not getting what they need. If they need something on top of that, which I highly doubt, then they could use some other method. Perhaps a global variable so they know what to do with the data as it comes in. Who knows, thats up to the user to determine in their program.

>> But to make it easier on the user I would like to do more of an automated method...
The automated method is not necessarilly the easier or better method to use.

Here's what you could do. Say you have a DLL function, foo(), that you want users to be able to override if they so choose. Say the DLL also provides another function similiar to: InitUserExtensions(HMODULE hmod). The hmod parameter is the module handle of the user's module which exports the user enxtension(s). Your DLL will then use GetProcAddress("foo_ext") and if a non-zero value is returned, then you know the user wants to override foo().

For this to work, the user has to:
- export the extension functions
- give the extension functions the correct name
- call InitUserExtensions()

For the function-pointer method to work, the user has to:
- call your DLL to set the new function pointers to use

I choose the second method. If there are multiple functions than can be overridden, then use a structure so that the user can provide multiple overrides with a single DLL call.

gg