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
fishcorn gmail.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://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
Boost-langbindinglists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/boost
-langbinding
|
