[
https://issues.apache.org/jira/browse/THRIFT-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806916#comment-13806916
]
Vitali Lovich commented on THRIFT-2242:
---------------------------------------
I respectfully disagree. C++11 support has been around for quite a while now
(past 2 years now), C++14 support is around the corner across the board with
the major compilers (Visual Studio, clang & gcc).
shared_ptr support:
Visual Studio 2008 (5 years old) as tr1
Visual Studio 2010 (3 years old)
gcc 4.1 (7 years old) as tr1
gcc 4.3 (5 years old)
clang 2.9 (2+ years old) - it's a newer project so never had tr1 & I can't
pinpoint the exact time it got shared_ptr
The problems with boost::shared_ptr:
* It forces a dependency on boost onto the client
* boost::shared_ptr may be broken on some platforms (i.e. arm). there is lag
between when boost::shared_ptr is fixed & when the platform is released.
* specific versions of boost may be required to be used (e.g. large
organizations) which may have incomplete/incorrect support for the platform
(e.g. the pre-processor macro may select the broken implementation of
shared_ptr)
* boost::shared_ptr has all sorts of different compilation options (using
threads, spinlocks, atomics, compiler intrinsics etc): the client has to be
careful that the boost library, the generated code & the client code that uses
it all is compiled with the same flag.
I understand the testing burden, but I don't see how this would get affected by
upgrading compilers (this issue is about codegen, not the library). In fact, I
think there's no additional switch even necessary; it MUST only use the
shared_ptr that the library is compiled with, otherwise it won't even compile.
If std::shared_ptr is available, then so is C++11 support.
> Generate C++11 code
> -------------------
>
> Key: THRIFT-2242
> URL: https://issues.apache.org/jira/browse/THRIFT-2242
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
> Affects Versions: 0.9.1
> Reporter: Vitali Lovich
>
> unordered_map instead of map, unordered_set instead of set, noexcept instead
> of throw() (unless the exact semantics of throw() are needed which seems
> unlikely).
> It should use the shared_ptr implementation that the library is configured
> with.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
