[ https://issues.apache.org/jira/browse/MESOS-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gavin updated MESOS-864: ------------------------ Comment: was deleted (was: www.rtat.net) > Eliminate the use of internal stdlibc++ templates for achieving libc++ > compatiblity > ------------------------------------------------------------------------------------ > > Key: MESOS-864 > URL: https://issues.apache.org/jira/browse/MESOS-864 > Project: Mesos > Issue Type: Improvement > Components: build, libprocess > Affects Versions: 0.14.2 > Environment: Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM > 3.3svn), libc++ (_LIBCPP_VERSION) 1101 > Reporter: Till Toenshoff > Assignee: Benjamin Hindman > Priority: Minor > Labels: build, clang, libc++, libprocess, stdlibc++ > Fix For: 0.17.0 > > > When attempting to build libprocess against libc++ most pitfalls are simply > namespace related (::tr1) but some are harder to come by. > One example is the use of std::tr1::_Bind within deferred.hpp. > [3rdparty/libprocess/include/process/deferred.hpp] > For the specific example, a comment was given for reasoning the design choice: > <pre>The result of invoking the 'defer' routines is actually an internal > type, effectively just a wrapper around the result of invoking > 'std::tr1::bind'. However, we want the result of bind to be castable to a > 'Deferred' but we don't want anyone to be able to create a 'Deferred' so we > use a level-of-indirection via this type.</pre> > How could we solve this without deriving directly from _Bind? -- This message was sent by Atlassian JIRA (v7.6.3#76005)