When writing an unmanaged Win32 DLL that exports functions, it's not uncommon to have some functions, variables and/or classes that aren't meant to be exported and are only for internal use within the DLL. Since we were targetting applications written in both .NET and Visual FoxPro at the time, using a
.def file instead of the
__declspec(dllexport) keyword was the way to go.
When writing components of this nature in a DLL the way I usually do it is with a
#define that expands to nothing but helps me keep track of what the purpose behind the component is, i.e.:
#define INTERNALUSE // Function used internally by the DLL VOID WINAPI INTERNALUSE StrDateToNumDate(wchar_t *wszDateString, int cchDate); // Function exported by the DLL BOOL WINAPI ValidateDateString(wchar_t *wszDateString, int cchDate);
One of my coworkers at this company had commented that this was confusing and bloated the code at the time when I wrote the component, and that, usually, the appearance of an additional keyword in a function definition in a DLL implies that the function is going to be exported (a la the
#define PROJECTNAME __declspec(dllexport) lines automatically generated by MSVC), but I found it much easier to keep maintain this way.
I haven't thought about this issue for a while but digging through some of my old code brought it back to my mind just now. I am curious if anyone has any insight on this topic and on which of us was more correct.