Re: MSVC C4251

David Abrahams wrote:
> on Mon Jun 11 2007, John Moeller <fishcorn-AT-gmail.com> wrote:
> 
>> [I wasn't able to successfully post this to the list via NNTP, 
> 
> I beg to differ :)

Heh, it took both a long time to appear; sorry for the spam.

>> After finally writing a Jamfile.v2 that works, I get a C4251 warning
>> when the DLLs build, because backend::call_xxx_data has a std::vector of
>> boost::shared_ptr<void>.
> 
> What do you mean by "has?"

By "has" I mean that call_xxx_data has a 
std::vector<boost::shared_ptr<void> > member.

>> I had implemented a tweak for MSVC that enabled the exportation of
>> std::vector<boost::shared_ptr<void> > (and the corresponding
>> allocator).
> 
> Sorry, that's too vague for me to get any useful information.

It's me who should apologize; I have a vagueness problem.  :)  I'll be 
more specific.  I said "tweak" because "hack" isn't the right word; 
there's an MSVC-specific workaround to the issue of template object data 
(like std::vector<> objects) that moves or is referenced across a DLL 
boundary.

They recommend that you explicitly instantiate the templates in the DLL 
with __declspec(dllexport).  For example:

template class __declspec(dllexport)
std::allocator<boost::shared_ptr<void> >;
template class __declspec(dllexport)
std::vector<boost::shared_ptr<void> >;

And that you "extern" the same template instantiations in whatever 
imports them:

extern template class __declspec(dllimport)
std::allocator<boost::shared_ptr<void> >;
extern template class __declspec(dllimport)
std::vector<boost::shared_ptr<void> >;

What this does is to treat the template instantiation as an exported 
class for the purposes of a DLL interface -- the "extern" lets the 
client code just import the template specialization.

Obviously, I had to add some macros to aux_/config.hpp to make it so 
that the header would work in both dll and client code.

The drawback to this is that any other TU in the client binary (exe or 
dll) would need to include call_xxx_data.hpp or some other header 
wherever the same vector instantiation appears, to avoid link errors. 
This doesn't seem particularly elegant to me.  In addition, every 
compiler that supports shared libraries will need similar tweaking.

>> I thought about it though, and it would only be useful if symbols
>> were decorated the same way in both the exporting DLL and the
>> importing binary.  Aren't symbol decorations
>> implementation-specific?
> 
> In principle, yes, although MSVC defines a de-facto platform standard
> that many others adhere to.

Does that mean that the ability to link a langbinding DLL built by one 
implementation into client code compiled in another should be supported?

>> If so, I should probably just disable C4251, rather than exporting the
>> vector and allocator specializations.  Or should I leave the export
>> tweak in there?
> 
> Don't know what it is, but it sounds like it's probably a mistake.

I'm leaning toward this conclusion as well, and thinking of one of the 
following solutions:

1.  Make certain that you're linking against a langbinding dll compiled 
by the same implementation as the client binary (i.e., just disable the 
warning)
2.  Move the vector out of the exported class and behind a pImpl; offer 
an interface for the private data
3.  Don't support a shared langbinding; let the specific binding link to 
langbinding statically and offer its own interface

Personally, (1) makes me nervous, given what you mentioned about other 
implementations adhering to MSVC's decoration standard.  (2) would 
probably be the most general solution.

-- 

John Moeller
[email protected]


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/