> It's not clear to me whether this bunch of warnings is all about
> pending_options_, or if all members of that class (or others!) are also
> being complained about. More data would help me to understand the
> common source of the problem.
I think the warnings are all for different instantiations of the STL
classes. Either where there is an STL member variable, or where a class is
derived from an STL class. Although as there's 83 warnings in total I
haven't checked them all. :-)
> The only thing common among them is that there seems to be some problem
> with static data. Since pending_options_ isn't static itself and is
> never accessed through inline methods, it would seem that the only
> thing it can be complaining about is that deque has a static member.
My understanding of the warning is that code within an application that uses
the library can't access the type referenced in the warning reliably. This
is because it's not exported, but is contained within an exported class. If
the application uses the non-exported class there may well be linker errors
due to different compilers / name mangling and the like. The reason the
errors only pop up for STL member variables is that the other classes have
all been marked as exported. In summary, I think you have to export
std::deque<OptionInfo> in the same way you do Query.
What I don't understand is why it warns in the case where it's a private
member variable that's not accessed from inline code. Although, as you've
probably guessed, I'm no expert in dlls and exporting!
> And that's one of the (few) strengths of VC++. (Be nice, Warren.) (And
stop talking to yourself.)
Ah, you must be a VB fan? ;-)