Boost C++ Libraries: Ticket #8092: stdlibc++ shipped by Apple does not provide std::move

Marshall Clow — Tue, 19 Feb 2013 14:09:00 GMT

You might want to check out this blog post that I wrote about clang and C++11, which addresses this very topic:

http://marshall.calepin.co/llvmclang-and-standard-libraries-on-mac-os-x.html

anonymous — Sat, 23 Feb 2013 19:21:14 GMT

marshall,

Thank you, I've read about this on stackoverflow. I see two problems here: Firstly, switching to libc++ means that end-user will have to compile boost with libc++ interfaces instead of using binary packages. And secondly, not any C++11 code will compile against libc++ as is.

I believe the problem can be solved with a few directives in config/stdlib/libstdcpp3.hpp like

// C++11 features in libstdc++ shipped with Apple Clang
#if __APPLE__ && (__GNUC_LIBSTD__ <= 4) && (__GNUC_LIBSTD_MINOR__ <= 2)
#  define BOOST_NO_CXX11_RVALUE_REFERENCES
#endif

owner, component, severity, summary changed

anonymous — Mon, 25 Feb 2013 09:14:40 GMT

owner changed from ebf to John Maddock
component variant → config
severity Regression → Showstopper
summary Apple clang does not provide std::move → stdlibc++ shipped by Apple does not provide std::move

So it seems like it is not a regression in Boost.Variant, but a small problem with Boost.Config.

cc set

John Maddock — Sun, 03 Mar 2013 13:33:51 GMT

cc mimomorin@… added

I'd rather not disable rvalue ref support as it disables a lot of functionality in other libraries which use rvalue refs but not std::move/forward.

There are a number of solutions, none of which are really very nice:

Declare this combination of compiler/stdlib as unsupported - either the user has to manually define BOOST_NO_CXX11_RVALUE_REFERENCES when they hit this (probably breaks other stuff) or switch to a supported configuration.
Add yet another config macro for std::move/forward. Unfortunately this is not as easy as it looks as there is no easy correspondence between libstdc++ versions and features (normally the GCC version gives us that, but using clang messes that up as well).
Add our own std::move/forward as a workaround - but this shares the configuration hell we have in the above case as well.
Suggest library authors use boost::move - but may be a heavyweight solution?
Suggest library authors use simple type casts (to rvalue reference) rather than std::move - but this uglifies code.

So... my inclination is to say "won't fix", but I'd welcome other ideas.

Also adding Michel Morin into this as he's edited clang.hpp quite a bit.

Marshall Clow — Sun, 03 Mar 2013 19:49:23 GMT

There's a clang-darwin config that we ship. (tools/build/v2/tools/clang-darwin.jam) Shouldn't these changes (whatever they turn out to be) go in there instead? (since the situation is particular to Mac OS X)

Note that there is at least one bug vs. the clang-darwin toolset. (#5957) [ Yeah, someone added a comment to a closed ticket. Really should be it's own ticket - but read the last comment ]

Michel Morin — Mon, 04 Mar 2013 08:40:03 GMT

Detecting the clang and libstdc++-4.2 configuration is not so difficult. (I needed to detect it in boost/type_traits/intrinsics.hpp to avoid the problems about __is_pod/__is_empty.) But I don't want to disable rvalue refs, since the compiler does support the feature.

Another solutions would be to use workaround implementations, but

We cannot add workaround implementations of std::move/forward as boost::move/forward, since the name boost::move/forward is already used by the Boost.Move library.
We cannot use boost::forward in Boost.Move as a drop-in replacement of std::forward, since boost::forward is not equivalent to std::forward. We cannot use static_cast<T&&> either, due to the same reason.

I don't think it's worth the effort to support this configuration. I would say "Don't turn on -std=c++0x option in this configuration or use another stdlib that supports C++11."

Michel Morin — Mon, 04 Mar 2013 09:36:23 GMT

We cannot use static_cast<T&&> either, due to the same reason.

I meant that std::forward<T>(x) is not always replaceable with static_cast<T&&>(x). See, for example, N2951.

Sebastian Redl — Mon, 04 Mar 2013 11:42:00 GMT

If Clang + libstdc++4.2 is detectable, then adding our own std::forward/std::move seems by far the best solution.

anonymous — Mon, 04 Mar 2013 17:20:29 GMT

So a possible fix would be to add:

#if !defined(BOOST_NO_CXX11_RVALUE_REFERENCES) \
  && defined(__APPLE__) && defined(_GLIBCXX_VERSION) \
  && (_GLIBCXX_VERSION <= 20070719)
// move and forward go here
#endif

But where do we add this? The obvious place is in config/suffix.hpp but as move/forward depend on remove_reference that's a really bad idea (cyclic dependencies etc). Does clang have an intrinsic for remove_reference? If so we could make it a clang specific fix in clang.hpp I guess...

John.

Marshall Clow — Mon, 04 Mar 2013 17:48:03 GMT

As people propose solutions, I want everyone to keep in mind:

This is not a "clang problem". This is a "clang on Mac OS X when used with the old version of libstdc++ that Apple ships" problem. If you have a modern libstdc++, this is not a problem. If you use libc++, this is not a problem.

Any solution should should be very constrained, so as not to break other systems - hence my suggestion earlier to consider the clang-darwin toolset.

Michel Morin — Mon, 04 Mar 2013 18:46:10 GMT

Do we really need to detect the clang and libstdc++-4.2 configuration?

What's the problem of always using Boost versions of move/forward

template <typename T>
inline T&&
forward(typename boost::remove_reference<T>::type& t) BOOST_NOEXCEPT
{
    return static_cast<T&&>(t);
}
template <typename T>
inline T&&
forward(typename boost::remove_reference<T>::type&& t) BOOST_NOEXCEPT
{
    BOOST_STATIC_ASSERT(!boost::is_lvalue_reference<T>::value);
    return static_cast<T&&>(t);
}
template <typename T>
inline typename boost::remove_reference<T>::type&&
move(T&& t) BOOST_NOEXCEPT
{
    return static_cast<typename boost::remove_reference<T>::type&&>(t);
}

John Maddock — Thu, 18 Apr 2013 16:05:41 GMT

What's the problem of always using Boost versions of move/forward

Well it means changing a lot of library's code, in order to support a compiler/stdlib configuration that's basically broken and isn't itself supported by it's vendors.

My gut feeling is to close this as "won't fix", Marshall you're more familiar with this platform than I am, is that reasonable?

viboes — Sun, 09 Jun 2013 19:38:45 GMT

I believed that we decided to don't support this combination.

+ 1 do "won't fix"

Marshall Clow — Sun, 09 Jun 2013 20:06:13 GMT

I concur with "won't fix".

If you want to use C++11 stuff on Mac OS X, use a C++11 compliant compiler _and_ a C++11 library. (aka clang and libc++).

status changed; resolution set

viboes — Wed, 12 Jun 2013 21:20:00 GMT

status new → closed
resolution → wontfix

koala0xcafe — Thu, 19 Sep 2013 00:03:15 GMT

that's due to the weirdo support of 2010 kind of inner faulty bridge, if set your target to cxx98 or fully built against cx11 there is no issue, this bug should be sent at Apple with the dedicated mention "swap your arse guys", numerous issues are logged because of the new itunes e.g xcode 4 which is a mess, buggy and a robbery.