Re: Inconsistency in exported symbols between different compiler versions
Eugene Gershnik wrote:
Ulrich Eckhardt wrote:
I have a library (a DLL) and that lib exports a type. This type is
derived publicly from std::pair<>.
Does the std::pair<> instanciation depend on your derived type? If yes the
answer to your question is provided at
http://msdn2.microsoft.com/en-us/library/twa2aw10.aspx
<quote>
class __declspec(dllexport) D : public B<D> {
// ...Because this is common pattern with templates, the compiler changed
the semantics of dllexport when it is applied to a class that has one or
more base-classes and when one or more of the base classes is a
specialization of a class template. In this case, the compiler implicitly
applies dllexport to the specializations of class templates. In Visual C++
.NET, a user can do the following and not get a warning:
class __declspec(dllexport) D : public B<D> {
// ...</quote>
Thanks for that info, but the std::pair<> instantiation doesn't depend on my
type, it is a simple pair<unsigned long, unsigned long> holding a version
number.
Now, what I found during the
research was that this DLL also exports functions for std::pair, in
this case constructor, destructor and assignment operator, but only
when compiled with VC7.1 and later, not with eVC4. Why?
Looks like the case above. eVC4 behaves more or less like VC6 that didn't
have this feature.
Yes, just for the record the compilers that come with eVC4 report versions
12.00-12.02, the one from VC6 reports 12.00.
I'm currently trying to figure out a way to remove the std::pair from
the interface of the DLL without breaking the interface (which would
be my next option, and not necessarily the worst since the interface
has assembled some dust already and a new version is called for).
As a general rule don't export classes derived from something you don't
control. You can use explicit dllexport on each public member to achieve
the same effect (but you will have to write down the implicitly generated
ones).
Hmmm, I don't think that is a good advise. There are two reasons why not:
1. It shouldn't matter.
Yes, I don't have control over std::pair<>, but I assume that for every user
of my class it will be the same. With this assumption, everything stands
and falls, and nothing (not even explicitly dllexporting the instantiation)
can prevent failure if someone tries to use my library with a different
std::pair implementation.
This also means that if the visible std::pair<> template is the same for my
library and the one using it, any symbols that were not resolved internally
can be generated from the template so they are available without being
exported from my lib.
2. It could lead to symbol clashes.
If two libraries both used the explicit dllexport to export the same
template instantiation, I couldn't link both libraries to the same project
without resolving to linker hacks (I think, I didn't really verify that).
Lastly, and that is another thing that puzzles me, I don't understand why
the compiler would handle baseclasses and members differently. I understand
that it has to embed code inline for both, but I don't understand why it
suddenly needs to export its functions when it derives from a template
class.
Uli