Boost logo

Boost Users :

Subject: Re: [Boost-users] [future] [Visual Studio 8.0] [1.42.0] Include File compiler failure
From: Robert Douglas (rwdougla_at_[hidden])
Date: 2010-04-14 10:43:15


Sorry to reply to my own post, but I found a solution, though it requires a
code change to boost:

struct all_futures_lock
{
      unsigned count;
      boost::scoped_array<boost::unique_lock<boost::mutex> > locks;

      all_futures_lock(std::vector<registered_waiter>& futures):
            count(static_cast<unsigned>(futures.size())),locks(new
boost::unique_lock<boost::mutex>[count])
      {
            for(unsigned i=0;i<count;++i)
            {

locks[static_cast<std::ptrdiff_t>(i)]=boost::unique_lock<boost::mutex>(futures[i].future->mutex);
            }
      }

      void lock()
      {
            boost::lock(locks.get(),locks.get()+count);
      }

      void unlock()
      {
            for(unsigned i=0;i<count;++i)
            {
                  locks[static_cast<std::ptrdiff_t>(i)].unlock();
            }
      }
};

Note the 3 static casts, the first is to avoid a warning, and the second two
are to explicitly convert the unsigned variable to std::ptrdiff_t.

VS 8.0 file "Microsoft Visual Studio 8\VC\include\crtdefs.h" line 516
defines ptrdiff_t as being "_w64 int" type.

Thus, the T& scoped_array<T>::operator[](std::ptrdiff_t i) const function
has an argument mismatch with unsigned. I realize that unsigned should
convert to int just fine, so I'm not sure if this is a compiler issue or
not.

First Question: Is there anyone with a bit more experience on implicit
conversions who can shed some light on whether or not the unsigned should be
implictly converted to int, or whether a default function should be matched?
Other question, is where is this *other* function coming from? Looking
through the preprocessed file, I cannot find any other places where there is
a operator[] being used on a scoped_array of any type.

Second Question: Is is safe for me to change this header file, and build
against it, while linking against the libraries which were built without
this change? If not, can anyone suggest a better way to achieve this without
having to modify the boost header?

Thanks!
-RD



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net