Aurelien Regat-Barrel wrote:
I also use this trick in _DEBUG only, because in release I don't use
dlls. I also recommend not to export STL classes, e.g. not to use STL
types in dll interfaces.
If the DLL is a plugin, I always make sure not to use STL in exported
functions. My plugin architecture is such that any C++ compiler can be
used to write plugins. I often use a pure C interface for plugins. I
also assume that the plugin uses a different memory allocator than the
main application. Handling that requires special attention, such as
passing an allocator function to the DLL, or the DLL has to expose a
cleanup function (create and free pairs).
But that's a major pain, and it requires wrappers. It's way too
time-consuming for everyday programming. I'm not going to stop using the
STL in my normal (non-plugin) modules. I'm not going to write my own
containers just because C++ is an inherently non-portable language
(binary portability is absolutely non-existant). It's mainly a fault of
the operating system for not providing transparent object-oriented DLL
architecture. .NET is supposed to fix that with mixed success.
When I modularize my application, I have a choice to use either LIB
files or DLLs. LIBs are not any better, because they still require that
you use the exact same compiler, same STL version, and same compiler
options. It's still easier to work with DLLs, because they're already
linked, and stable DLLs don't change. Also using DLLs it's possible to
fix a bug in an application without having to rebuild the entire
application. This increases long-term stability, as opposed to a full
rebuild, which would be needed with LIBs. It's a big advantage to me to
have dynamic modules, even if they can be tossed away when upgrading to
a new compiler. I know what I'm doing is not portable, and I can safely
disregard those warnings regarding not exporting STL classes.
It would be nice to be able to disable those warnings explicitly for
each line. Something that would tell the compiler that I acknowledged
that and I still want to do it, don't show that warning for that line
anymore. Disabling all warnings is not good, and leaving the warnings in
just makes everyone disregard all warnings after a while, because we get
overwhelmed. Right now the solution is to rebuild everything with full
warnings enabled once a month or so, but turn a lot of those warnings
off during everyday development. It's not an ideal situation.
Tom