0

I have inherited a large C++ project in which a multithreaded executable loads a few dozen DLLs. On Windows, the DLLs are loaded using LoadLibrary(), and the entry points to the DLLs are accessed using GetProcAddress().

One of the entry points in each DLL is a function called MyEntryPoint, declared like this on Windows:

extern "C" __declspec(dllexport) void MyEntryPoint() 

MyEntryPoint() needs to call helper functions inside the DLL where it is defined. The helper functions do not need to be exported outside of the DLL in which they are declared because they are used only locally. However, several DLLs have functions with the same name. Example: in several DLLs, there is a function declared as:

void MyHelperFunction()

which is called by MyEntryPoint(). In some DLLs, MyHelperFunction() is declared static, but not in others. (Over the years, there have been many hands in the code, with varying levels of understanding and expertise.) Does declaring MyHelperFunction() as static avoid cluttering the global namespace, or is there another reason for doing it?

echawkes
  • 447
  • 2
  • 12
  • Are the `MyHelperFunction()` functions declared and defined only in the .cpp files? – R Sahu Jul 16 '18 at 21:42
  • Related: [What is external linkage and internal linkage?](https://stackoverflow.com/questions/1358400). – Remy Lebeau Jul 16 '18 at 21:44
  • @r-sahu The DLLs don't have .h files. The `MyHelperFunction()` functions are declared and defined only in the .cpp files. – echawkes Jul 16 '18 at 21:46
  • 'Varying levels of understanding', there doesn't have to be a good reason. The obvious way to avoid name collisions would be to pick sensible and meaningful names in the first place. Since that simple thing hasn't been done I doubt you're going to find many good reasons for the code you've inherited. – john Jul 16 '18 at 21:47
  • @echawkes, in that case, I would recommend changing all of them to `static`, if that's an option. The current state of mixed up styles is most likely because of missing or inconsistent coding guidelines. – R Sahu Jul 16 '18 at 21:48
  • 1
    `static` and `__declspec(dllexport)` are orthogonal. `static` relates to linker symbol viability. Unless marked with `__declspec(dllexport)` non-static symbols will not be put in the module export table. – Richard Critten Jul 16 '18 at 21:48
  • ^^^^^... [module definition file exports notwithstanding](https://learn.microsoft.com/en-us/cpp/build/reference/exports) . – WhozCraig Jul 16 '18 at 23:05

1 Answers1

1

If library interface is defined via explicit __declspec((dllexport) annotations static won't cause any changes. If library interface is defined via .def file (which is unlikely), declaring function as static would preclude it's usage in .def file.

In addition to above, static would inform compiler that function is only accessible from current translation unit which allows more optimizations (e.g. inlining and cloning are done more aggressively) so it's always beneficial to use it.

yugr
  • 19,769
  • 3
  • 51
  • 96