[
https://issues.apache.org/jira/browse/THRIFT-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806987#comment-13806987
]
Vitali Lovich edited comment on THRIFT-2242 at 10/28/13 5:46 PM:
-----------------------------------------------------------------
The config.h would only detect boost:: or std:: if the ./configure line had
something like \--with-c++11 \(over time that may become the default, but
certainly now is too early\), so I don't really see the compiler upgrade as a
serious issue. unordered_map/map & unordered_set/set also have incompatible
APIs; if the client wants to adopt C++11 we should take the opportunity to do
it across the board.
The "experimental" refers to backwards compatibility, not that it may not work
or that it's still buggy. The only part of the library that would be in-use
(shared_ptr, unordered_map, unordered_set) are pretty safe in terms of not
being part of experimental (non-backwards-compatible language feature changes
do not affect ABI).
GCC 4.1 has tr1, so it certainly is an option for them. That being said,
clients using desktop software (especially software 6 years old) are unlikely
to be running into issues with boost not being supported on their platform.
"If boost is broken on a platform, chances are pretty good that Thrift is also
broken on that platform, even if it used std:: constructs."
You are misstating what I said. I said boost::shared_ptr is broken, not boost.
For example, thrift works just fine on iOS with boost 1.53. For certain
reasons, I have to use boost 1.51. boost 1.51 shared_ptr is broken on iPhone 5
& newer (it also doesn't detect clang properly for some reason & uses spinlocks
instead of atomics). The only remaining user of boost::shared_ptr in my
project is thrift, which I have to degrade to use pthreads (& I have to hope
that I've defined BOOST_SP_USE_PTHREADS everywhere). Additionally, I'm not
sure if boost even supports the iPhone 5S yet.
was (Author: vlovich):
The config.h would only detect boost:: or std:: if the ./configure line had
something like \--with-c++11 (over time that may become the default, but
certainly now is too early), so I don't really see the compiler upgrade as a
serious issue. unordered_map/map & unordered_set/set also have incompatible
APIs; if the client wants to adopt C++11 we should take the opportunity to do
it across the board.
The "experimental" refers to backwards compatibility, not that it may not work
or that it's still buggy. The only part of the library that would be in-use
(shared_ptr, unordered_map, unordered_set) are pretty safe in terms of not
being part of experimental (non-backwards-compatible language feature changes
do not affect ABI).
GCC 4.1 has tr1, so it certainly is an option for them. That being said,
clients using desktop software (especially software 6 years old) are unlikely
to be running into issues with boost not being supported on their platform.
"If boost is broken on a platform, chances are pretty good that Thrift is also
broken on that platform, even if it used std:: constructs."
You are misstating what I said. I said boost::shared_ptr is broken, not boost.
For example, thrift works just fine on iOS with boost 1.53. For certain
reasons, I have to use boost 1.51. boost 1.51 shared_ptr is broken on iPhone 5
& newer (it also doesn't detect clang properly for some reason & uses spinlocks
instead of atomics). The only remaining user of boost::shared_ptr in my
project is thrift, which I have to degrade to use pthreads (& I have to hope
that I've defined BOOST_SP_USE_PTHREADS everywhere). Additionally, I'm not
sure if boost even supports the iPhone 5S yet.
> 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)
