Subject: Re: [Boost-bugs] [Boost C++ Libraries] #5341: Patch to improve shared library behavior with serialization
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2011-04-23 01:51:50
#5341: Patch to improve shared library behavior with serialization
Reporter: Aaron Barany <akb825@â¦> | Owner: ramey
Type: Patches | Status: closed
Milestone: To Be Determined | Component: serialization
Version: Boost 1.46.0 | Severity: Problem
Resolution: wontfix | Keywords: serialization shared_libraries dlls
Comment (by Aaron Barany <akb825@â¦>):
The problem with the current method is all instantiations of
archive_serializer_map are always set to export for the boost
serialization DLL, and set to import for all other libraries, which causes
issues due to the fact that itâs templated. This makes it impossible to
create your own archive outside of the boost serialization DLL. I will lay
out every step of why this is the case.
I will first start with how template instantiation works. When you
instantiate a templated class, it is as if you are creating a completely
new, unrelated type. For example, letâs say you have a template class Foo.
If you have a template instantiation for type A and type B, you have
Foo<A> and Foo<B>. As far as the compiler is concerned, you might as well
have separately created two unrelated classes, Foo_A and Foo_B.
Additionally, these separate templated types are created in whatever
library they are instantiated in. For example, letâs say you declare your
templated Foo type in Library1, and instantiate Foo<A> in Library2 and
Foo<B> in Library3. This is equivalent to creating nothing in Library1,
creating a class Foo_A in Library2, and a completely unrelated class Foo_B
Now I will cover how DLL symbol importing and exporting work in the
Microsoft compiler. When compiling a library, you must declare all symbols
you want to expose to external libraries to export. When compiling code
that utilizes that library, all declarations of those symbols must be
declared to import. Exported symbols must have an implementation, while
imported symbols may not have an implementation. Choosing whether to
export or import a symbol is typically done with a macro, which resolves
to export when compiling the library, and import when compiling other
libraries and executables that utilize that library.
Now in this case we must combine both templated classes and DLL importing
and exporting to fully understand the archive_serializer_map symbol
exporting. In this case, letâs again use the Foo class used above. The
way the archive_serializer_map is implemented, it is the same as saying
that all instantiations of the Foo templated class exports symbols when
compiling Library1, and imports symbols when compiling anything else. This
causes problems when you instantiate Foo<A> in Library2 and Foo<B> in
Library3. In both these cases, the compiler thinks it needs to import the
symbols for both Foo<A> and Foo<B>, since it is set up to export from
Library1, and import everywhere else. However, since Foo<A> and Foo<B> are
being created in different libraries, you actually want Foo<A> to export
symbols when in Library2, and Foo<B> to export symbols when in Library3.
The method that I use in the patch achieves this, and allows you to
specify for each template instantiation of the archive_serializer_map
whether itâs importing or exporting symbols independently.
I will admit that this is different from how the rest of boost works, but
at the same time the rest of boost doesnât export DLL symbols for
templated classes, so it will be different no matter what you do. The way
itâs currently set up, based on what I laid out above, you can only create
archives in the boost DLL, since it will always export the symbols in the
boost DLL library and import the symbols in all other libraries regardless
of where the template is instantiated. My changes in my patch allow you to
export those symbols in other libraries. If you refuse to change it, then
you must accept the fact that users will never be able to create their own
archives when using DLLs. Ever.
Also, I am wondering why you marked this as âwonât fixâ. Your issue was
with the DLL importing/exporting. While this is necessary if you want to
create your own archives, there are other aspects of this patch that donât
rely on that. The other archive_serializer_map and basic_serializer_map
changes deal with the serializers being instantiated in multiple
libraries, which is completely unrelated. Like I said before, please ask
me if you need clarification for any details, but please donât close this
just because you donât understand it.
-- Ticket URL: <https://svn.boost.org/trac/boost/ticket/5341#comment:5> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:06 UTC