MFC Application with different DLLs(having same function name)

aravind sn

hello, im bit new to MFC, actually i have to write an MFC application, say it depends on three DLLs but not simultaneously, The function names are same in all 3 DLLs but with the changed functionality. any how i guess i cannot include all these 3 dlls in the project settings, because of the ambigious functions in each DLLs. Can any provide me a solution for this -thanks aravind

Stuart Dootson

You need to use explicit DLL linking. Here's an example. Let us say the function is called Test and has the same signature in all three DLLs (because that simplifies things), which is int Test(int). Then we can do this:

// Declare a type for the function we want to load.
typedef int (*pTest)(int);
// Function that tries to get a nfunction named Test from the DLL we pass it.
pTest GetTestFnFromDll(LPCTSTR dllName)
{
// Load the DLL
   HMODULE hDll = LoadLibrary(dllName);
   if (!hDll) return 0;
// Get the function address
   return (pTest)GetProcAddress(hDll, "Test");
}

int main()
{
// Use first.dll!Test
   pTest aTestFn = GetTestFnFromDll(_T("first.dll"));
   if (aTestFn)
      std::cout << aTestFn(10) << std::endl;

// Use second.dll!Test
   pTest aSecondTestFn = GetTestFnFromDll(_T("second.dll"));
   if (aSecondTestFn)
      std::cout << aSecondTestFn(10) << std::endl;

return 0;
}

HTH!

Rajesh R Subramanian

Seriously though, how can three different DLLs export functions with the same exact name? Please tell me you are not the author of those DLLs. If you are, you need to fix it there and not where you consume it.

It is a crappy thing, but it's life -^ Carlo Pallini

Stuart Dootson

Rajesh R Subramanian wrote:

Seriously though, how can three different DLLs export functions with the same exact name?

It all depends on the requirements! Seriously - I've got a system that extracts symbol information (variable names, addresses, types etc) from debug information. I support several different flavours of debug information (Microsoft PDB, Dwarf1, STABS) and the parser for each different type of information is contained in a separate plugin DLL. Each of these DLLs exports a routine called GetParsers, which gives you access to each of the (singleton) parsers in the DLL. Similarly, COM DLLs have a similar structure (DllRegisterServer[^], DllGetClassObject[^]). So, yeah, it's a valid design pattern - whether or not the OP actually meant to do that is another matter, of course :-)

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

Rajesh R Subramanian

Stuart Dootson wrote:

So, yeah, it's a valid design pattern - whether or not the OP actually meant to do that is another matter, of course

Which, I was pretty much worried about. I also doubt that he just needs overloaded functions (and couldn't keep 'em all in one DLL), so he wrote 3 DLLs, but to get stuck while trying to consume it. All are assumptions though. OT: BTW, I ran into trying to debug a release mode binary and it took me 10 minutes to figure that out. :doh: I just happened to remember the conversation we had the other day. :)

It is a crappy thing, but it's life -^ Carlo Pallini

aravind sn

hi stuart thanks a lot,, i luk in to that,, (its late night here,, im leaving)im quite new so need to cover ur suggestion in detail hi rajesh, thanks for you too for the reply, actually the 3 DLLs are the c middleware i got that from the customer, and all three are for different language support, so if i select German, My application ll select the 1st first DLL and its functionality to process the text-contents, if i select the French , then 2nd DLL, if its English then 3rd DLL,. I have no rights to change these DLLs -regards aravind

aravind sn

thanks stuart,, it really worked the way u suggested, thanks a lot, thank you rajesh for responding to the post -regards aravind