[
https://issues.apache.org/jira/browse/THRIFT-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13558151#comment-13558151
]
Ben Craig commented on THRIFT-1834:
-----------------------------------
So I'll lead off by saying that I care about Thrift, but I'm not one of the
maintainers. I do have years of experience in dealing with C++ binary
compatibility.
In particular, my company develops multiple pieces of software that share
common infrastructure. The common infrastructure must maintain backwards
binary compatibility. If the infrastructure were to break binary
compatibility, mixing two different packages of our software that had different
infrastructure versions would either prevent our programs from loading, or
cause subtle crashes.
I'm going to tackle your concerns out of order.
bq. "Surely the excuse for boost/STL does not hold."
I'm afraid it does. Boost types and STL types don't maintain binary
compatibility among major versions. The support for those libraries is often
provided by a dynamic library, but that doesn't mean that the types themselves
maintain binary compatibility. When dealing with types like this, it's best
not to think of the type as a "std::string" or "boost::shared_ptr", but an
"msvc10!std::string" and a "boost_1_50!boost::shared_ptr". As long as the
caller and callee agree on the version, compatibility is preserved. If you
suspect you will ever be in the situation where caller and callee can't match,
then you should avoid using those types in binary interfaces.
Suppose you had a Thrift!TSocket built with msvc10, and you shipped something
else, independently that called into it, and that caller was built with msvc10.
If you wanted to maintain backwards compatibility on Thrift!TSocket, you
wouldn't ever be able to upgrade compilers. There are some tricks you can do
to make this sort of possible, like versioning the DLL, but then the solution
starts feeling more similar to static libraries.
bq. "I can't see why if we decide to stick to a particular Thrift milestone
build/release (I.e.: 0.7, 0.8, 0.9, etc...) it can't be dynamically linked to
the applications/libraries that are built against it."
If Apache were to provide the binaries, Apache would need to provide a lot of
build variants. Take every combination of supported Visual Studio versions,
supported boost versions, supported build configurations (release / debug), and
possibly a few other flavors.
If Apache doesn't provide the binaries, then anyone that wanted dynamic builds
would need to provide that set of binaries, though trimmed to their use case.
By trimming the use supported combinations, you make the problem reasonable,
but it is still a lot of work, and the developer tax of having the wrong one
installed can add up quick.
bq. "Also, I'm not sure I understand what you mean by 'Thrift is designed to be
packaged as a static library'. What real advantages do we get from statically
linking Thrift to our applications/libraries that we wouldn't get if we
dynamically linked to them ."
I might have misspoken there. I don't think that Thrift was necessarily
designed as a static lib, as it wasn't proactively designed as a dynamic lib.
Good dynamic lib interface design involves minimizing the size of your
interface, and giving yourself as much wiggle room as possible to allow you to
make changes to the implementation in the future. Thrift's interfaces haven't
been given that kind of attention. Those kinds of changes typically have a
runtime cost though. Well insulated classes require more indirections, more
virtual functions, and more heap allocations.
There are upsides to being a static library. If you only have one application
using Thrift per machine, then a static library is almost certainly going to
use less disk space and less memory. Static libraries will optimize better
than dynamic libraries, giving you a little bit better runtime performance.
And to reinforce my earlier points, with a static library, you don't need to
worry about binary compatibility, or matching the right DLL with your exe.
bq. "Would this current design decision to be packaged as a static library be
reconsidered once Thrift reaches 1.0.0?"
Someone would need to provide a patch first. I don't know what the
maintainers' opinion of a DLL version of Thrift is. If a DLL version were
available, I would not be able to use it for my projects.
> Unable to build C++ Thrift dynamic library on Windows
> -----------------------------------------------------
>
> Key: THRIFT-1834
> URL: https://issues.apache.org/jira/browse/THRIFT-1834
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
> Affects Versions: 0.9
> Environment: Windows x86_64 MSVC 2010
> Reporter: Chris Stylianou
> Labels: dll, msvc, thrift, windows
>
> I am unable to build a valid .dll version of the Thrift C++ library using
> MSVC2010 as nothing has been declared with
> "__declspec(dllexport)/__declspec(dllimport)", meaning that MSVC2010 (and
> presumably all other versions) are unable to generate the import .lib that
> should accompany the .dll library.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
