Re: 2+2=4, but only once !?

Richard Maine wrote:

Unless.... I might (or might nit) recall some funniness about how initialization is handled in DLLs.

It's not "funny" if you think of DLLs as being code that is a part of your program -- then, the initialization on first call only makes sense. In fact, this is exactly the case and why they behave the way they do.

However, if you make the mistake of thinking of DLLs as being a separate entity that functions like a program, then you might indeed be surprised to find that variables are only initialized on first call and subsequently (if SAVEd or treated as though they are SAVEd) retain their last assigned value.

This is, obviously, a big potential issue with porting code designed to run as a standalone program into a callable DLL function. But that's not really specific to DLLs, as it would be equally an issue if the main program were modified to support calling the code multiple times in response to user input.
.

Relevant Pages

  • Re: Share .cpp and .h along projects
    ... You may not care about memory/disk/download time/execution time savings, ... As for DLLs having "nothing to offer", ... libraries. ... Initialization of function static variables is well-defined. ...
    (microsoft.public.vc.language)
  • Re: error R6031
    ... /clr compiler switch is not used in app neither in dlls. ... When MFC app is exited there appears error message: ...
    (microsoft.public.vc.mfc)
  • Re: mutual dependent DLLs and global variables
    ... DLLs should not be mutually dependent like this. ... topological sort of their dependency DAG. ... order of their initialization. ... >I'd say the best solution is to break the dependency. ...
    (microsoft.public.vc.mfc)
  • Re: MFC extension dll initialization
    ... dynlinklibrary in all dlls regardless of how they are loaded. ... shared dll dynamically linked). ... By initialization I mean this ... extern "C" extern void WINAPI InitXxxDLL() ...
    (microsoft.public.vc.mfc)