Re: Share .cpp and .h along projects
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.
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@mvps.org
MVP VC FAQ: http://vcfaq.mvps.org
=====================================
"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:ff61c3tt0otrfivah9ui5kmmjjh8o5lfui@4ax.com...
On Mon, 13 Aug 2007 12:26:43 -0500, "Ben Voigt [C++ MVP]"
<rbv@nospam.nospam> wrote:
It is incredibly fragile, non-standard behavior, that produces postings in
this newsgroup continually. The same behavior can be gotten in a robust,
compiler-independent way using COM-compatible binary interfaces. So why
use
__declspec(dllexport)?
Only __declspec(dllexport|dllimport) allows you to (mostly) use the
classes
as you would write them in normal C++. Using the __declspec should be
viewed as equivalent to static linking, and then you won't lament the fact
it isn't compiler-independent; after all, it was never intended to be. In
comparison, COM is a huge pain in the neck, and I wouldn't even consider
using it unless there was an actual need to use it.
--
Doug Harrison
Visual C++ MVP