Re: A problem about static object in DLL
Alex Blekhman wrote:
"Ben Voigt [C++ MVP]" wrote:
It is a very bad idea by itself. You shouldn't ever do it for
reusable code (meant to be consumed by more than one client
application), and even for application-private DLLs you'd need a
very good reason that can't be implemented any other way.
It is true for any code reuse, I agree. However, if you treat such
DLL as a static libary and use it as a private library for an
application, then you can benefit from better project modularity
and reduced build times. It is a small added value, but it is not
zero, nonetheless.
Which of those benefits don't you get from static libraries, without any of
the risk?
Recent reports are that the MS C++ Runtime Libraries, which
dllexport classes, managed to break spectacularly because of the
fragile export interface dllexport of classes creates.
What is so fragile about that? It is not much different from
exporting standalone functions, after all.
Let's start with "compatibility between compiler versions". Standalone
functions are, dllexport classes aren't. Note that by definition you aren't
passing for example std::string to the standalone function because you're
not permitted to dllexport it (opaque pointers a/k/a handles are acceptable
though, as long as they're only unpacking in the same DLL that created
them).
Alex