[Boost-bugs] [Boost C++ Libraries] #5040: future.hpp in boost::thread does not compile with /clr

Subject: [Boost-bugs] [Boost C++ Libraries] #5040: future.hpp in boost::thread does not compile with /clr
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2011-01-05 11:35:12

#5040: future.hpp in boost::thread does not compile with /clr
---------------------------------------------------+------------------------
 Reporter:  Colin Powers <colin.powers@…>          |       Owner:  anthonyw
     Type:  Bugs                                   |      Status:  new     
Milestone:  To Be Determined                       |   Component:  thread  
  Version:  Boost 1.45.0                           |    Severity:  Problem 
 Keywords:                                         |  
---------------------------------------------------+------------------------
 Including thread.hpp in a project using the /clr compiler flag results in
 the following output.

 {{{

 [...]\boost-1.45\include\boost-1_45\boost/thread/future.hpp(422) : error
 C2666: 'boost::scoped_array<T>:
 :operator []' : 2 overloads have similar conversions
         with
         [
             T=boost::unique_lock<boost::mutex>
         ]
         [...]\boost-1.45\include\boost-
 1_45\boost/smart_ptr/scoped_array.hpp(77): could be 'boost::uniqu
 e_lock<Mutex> &boost::scoped_array<T>::operator [](ptrdiff_t) const'
         with
         [
             Mutex=boost::mutex,
             T=boost::unique_lock<boost::mutex>
         ]
         or 'built-in C++ operator[(void (__cdecl *)(boost::scoped_array<T>
 ***), boost::detail::future_waiter::count_typ
 e)'
         with
         [
             T=boost::unique_lock<boost::mutex>
         ]
         while trying to match the argument list '(boost::scoped_array<T>,
 boost::detail::future_waiter::count_type)'
         with
         [
             T=boost::unique_lock<boost::mutex>
         ]
 [...]\boost-1.45\include\boost-1_45\boost/thread/future.hpp(435) : error
 C2666: 'boost::scoped_array<T>:
 :operator []' : 2 overloads have similar conversions
         with
         [
             T=boost::unique_lock<boost::mutex>
         ]
         [...]\boost-1.45\include\boost-
 1_45\boost/smart_ptr/scoped_array.hpp(77): could be 'boost::uniqu
 e_lock<Mutex> &boost::scoped_array<T>::operator [](ptrdiff_t) const'
         with
         [
             Mutex=boost::mutex,
             T=boost::unique_lock<boost::mutex>
         ]
         or 'built-in C++ operator[(void (__cdecl *)(boost::scoped_array<T>
 ***), boost::detail::future_waiter::count_typ
 e)'
         with
         [
             T=boost::unique_lock<boost::mutex>
         ]
         while trying to match the argument list '(boost::scoped_array<T>,
 boost::detail::future_waiter::count_type)'
         with
         [
             T=boost::unique_lock<boost::mutex>
         ]
 [...]\boost-1.45\include\boost-1_45\boost/thread/future.hpp(435) : error
 C2228: left of '.unlock' must h
 ave class/struct/union

 }}}

 I couldn't find any tickets on this problem however a quick google brought
 up someone who has encountered this before:
 http://groups.google.com/group/boost-

 list/browse_thread/thread/9662c882efc153b6?pli=1

 unsigned should probably convert to ptrdiff_t implicitly but it's throwing
 a wobbly with /clr. Maybe this is fair enough as specifying /clr opens a
 whole new world of pain (I was just trying my luck really!), nevertheless
 would it be sensible to change the types from unsigned to ptrdiff_t as
 that's what operator[] requires?

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/5040>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.