correct way to set up calling dll functions.
I use this in MSVC,
Code:
HMODULE __TESTDLL_DLL;
typedef void (WINAPI*__TestProc1) ();
__TestProc1 TestProc1;
typedef Integer (WINAPI*__TestProc2) (Integer Num1,Integer Num2);
__TestProc2 TestProc2;
typedef void (WINAPI*__TestProc3) ();
__TestProc3 TestProc3;
.
.
.
__TESTDLL_DLL= LoadLibrary("TESTDLL.DLL");
*TestProc1 = (__TestProc1)GetProcAddress(__TESTDLL_DLL,"TestProc1");
*TestProc2 = (__TestProc2)GetProcAddress(__TESTDLL_DLL,"TestProc2");
*TestProc3 = (__TestProc3)GetProcAddress(__TESTDLL_DLL,"TestProc3");
Both gcc and borland compilers complain at the three lines immediately above.
What am I doing wrong here?
Mike
Re: correct way to set up calling dll functions.
Leaving aside that identifiers starting with double underscores are reserved for the compiler and mustn't be used in end-user programs...
What are the errors?
Re: correct way to set up calling dll functions.
Quote:
Leaving aside that identifiers starting with double underscores are reserved for the compiler and mustn't be used in end-user programs...
Really, I did not know that. Is that gcc or borlands or both?
Is it only 2 underscores.
Anyway the error I was getting was.
D:\Release of SpeedBasic4.8.5\Examples\DllCall\Form1.cpp:35: error: assignment of read-only location
D:\Release of SpeedBasic4.8.5\Examples\DllCall\Form1.cpp:35: error: cannot convert `void (*)()' to `void ()()' in assignment
for each. The assignments should have been
TestProc1 = (__TestProc1)GetProcAddress(__TESTDLL_DLL,"TestProc1");
without the *.
Re: correct way to set up calling dll functions.
Quote:
Really, I did not know that. Is that gcc or borlands or both?
That is the official C++ standard. Note that I'm not aware of any compiler that will actually complain - it's just that there are some rules: the compiler will not use plain names for its own extensions, thus it will not trash your standards-compliant programs. But if you use double underscores, all bets are off: the compiler is free to have its own extensions use that name, which would make your program fail to compile. Which means that at any point in the future, your program may suddenly stop working, because you tried to compile them on a different compiler, or you just upgraded the one you were using.
Standards are there for interoperability.
