MSVC C4251

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

MSVC C4251

John Moeller
[I wasn't able to successfully post this to the list via NNTP, so I'm
trying again with the Mailman interface]

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>.  I had implemented a tweak for MSVC that
enabled the exportation of std::vector<boost::shared_ptr<void> > (and
the corresponding allocator).

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?

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?

--

John Moeller
[hidden email]


-------------------------------------------------------------------------
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/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: MSVC C4251

David Abrahams

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 :)

> so I'm trying again with the Mailman interface]

> 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?"

> 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.

> 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.

> 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.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

The Astoria Seminar ==> http://www.astoriaseminar.com


-------------------------------------------------------------------------
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/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: MSVC C4251

John Moeller
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
[hidden email]


-------------------------------------------------------------------------
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/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: MSVC C4251

John Moeller
John Moeller wrote:

> 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.
>

http://www.boost.org/more/separate_compilation.html

Bah.  Should have read that before posting.  Looks like the policy is to
just disable the warning.  Sorry for the trouble.

--

John Moeller
[hidden email]


-------------------------------------------------------------------------
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/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding