Re: Share .cpp and .h along projects
"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:11d1c39ijnaiema57ing2jeoacub7loa1v@4ax.com...
On Mon, 13 Aug 2007 12:12:51 -0700, "Alexander Nickolov"
<agnickolov@mvps.org> wrote:
COM is for binary compatibility. DLLs are binary objects
and it fits with them naturally. C++ classes are _not_ binary
entities and thus should _never_ be exported from DLLs -
period. It's a terrible deployment practice eclipising any bad
coding habits you might have! The proper way to export
C++ classes is using a static library. This signifies they are
part of your program, not part of a separate deployment unit.
This use of DLLs is not what you're calling "deployment". If you consider
it to be a poor attempt at COM and not equivalent to static linking, well,
of course you're going to feel that way. That's what I was getting at in
my
original message. It is mistaken expectations that cause people to say
things like this. You've mistaken it for something it's not, and anyone
who
recognizes it for what it is and uses it correctly and successfully just
doesn't know what they're doing.
An updated DLL is expected to be a drag+drop replacement for the old
version.
__declspec(dllexport) is going to break that all the time, in a way that a
COM-compatible interface (doesn't have to be COM-compliant with all the
extra registry stuff) won't.
If you have such close coupling, and are using DLLs for incremental loading
or some other purpose besides deployment, then make sure every update to the
DLL changes the filename so nobody confuses it for being compatible with the
previous version.
And deploying "reusable components" that way is a huge mistake, which seems
to be what it gets used for 99% of the time, causing the constant questions
in this group of "how can I use this library XYZ I bought from vendor ABC
two years ago with the new Visual Studio?"
Generally, if something is so closely coupled that using a pure virtual
interface isn't good enough, you need C++ class definitions, then it needs
to be statically linked. Remember that giving the compiler access to the
class definition causes it to start inlining... what's the purpose of
putting the class in a separate DLL if the implementation is partially
inlined into the caller? You might as well put only half of the member
definitions in this DLL, a third in a second DLL, and a few in yet another
DLL.