Re: Share .cpp and .h along projects
"Larry Smith" <no_spam@_nospam.com> wrote in message
news:OWwVdms3HHA.4900@TK2MSFTNGP04.phx.gbl...
No, DLLs expose functions and (very occasionally) global data.
The fact that the C++ compiler flattens the hierarchy of C++ class
members using name mangling, in such a way that they can be forced into
the DLL export table, doesn't mean that the DLL is truly exporting
classes. For what's necessary to *truly* export a C++ class, see
(http://www.comeaucomputing.com/4.0/docs/userman/export.html). DLLs do
not provide that. They do not even come close.
I never claimed this is equivalent to the "export" keyword which wasn't
even implemented outside of Comeau the last time I checked (quite sometime
ago). This issue has nothing to do with the "export" keyword however which
is a template mechanism. Note BTW that "export" has serious issues
surrounding it and Herb Sutter has even recommended removing it from the
standard altogether (in a paper read some years back).
Templates weren't what you were referring to when you said "C++ is more than
just classes"?
Among other things, C++ classes must abide by the ODR rule. DLLs provide
no help avoiding ODR violations.
"dllexport" is a documented MSFT extension that allows you to "export"
classes. It's that simple. Follow the rules and you'll be ok. All these
negative claims that you should never do this and never do that is
nonsense. I last used this feature some years ago and there were never any
problems. No ODR problems, no shared CRT library problems (when dealing
with memory across DLL boundaries), etc. Compiler-independence, the use of
COM, and other issues I've read in this thread are irrelevant to those who
don't need or want it. Someone also mentioned the difficutlites of using
COM as a deterrent. It is, and a very serious one since COM has a very
steep learning curve. Moreover, the C++ tools for creating COM objects
never matured properly. #import and the associated smart pointers was a
nice creation for COM clients, but for most COM server writers, ATL or
even MFC is a disaster waiting to happen (for most programmers).
COM is not necessary. Using v-tables the same way COM does, is. You don't
have to mess with apartments or registration or marshalling or remoting
contexts or pumping the message loop or any of that to export objects from
DLLs in a compiler-independent way.
The C++ tools for creating v-tables are quite mature in my experience. You
just use the "virtual" keyword and the "= 0" pure modifier, and create
helper "factory" functions to create and destroy the objects, which is
necessary anyway because objects have to be freed in the same module they
are created from to avoid heap corruption.