Re: [Boost-users] [Thread] this_tread::sleep won't compile with gcc, "no match for operator+"

Subject: Re: [Boost-users] [Thread] this_tread::sleep won't compile with gcc, "no match for operator+"
From: Alexey Malakhov (malakhov_at_[hidden])
Date: 2011-05-31 11:15:48

2011/5/30 Igor R <boost.lists_at_[hidden]>

> > Basically, what I'm trying to do is:
> >
> >     using namespace boost::posix_time;
> >     using namespace boost::this_thread;
> >
> >     time_duration td = milliseconds(2000);
> >     sleep(&td);
>
> Just curious: what's the purpose of the ampersand here?
>
> http://www.boost.org/doc/libs/1_46_1/doc/html/thread/thread_management.html#thread.thread_management.this_thread.sleep
>

Igor, thanks for the note. My ampersand came from VS refusing to compile
otherwise.
But you're right, semantically it should not be there.

And it's true, in win32 version this_thread::sleep() declaration is
inline void sleep(TimeDuration const& rel_time)
        {

interruptible_wait(detail::pin_to_zero(rel_time->total_milliseconds()));
        }
TimeDuration=boost::posix_time::time_duration

so rel_time->total_milliseconds() get a compiler error:
type 'boost::posix_time::time_duration' does not have an overloaded member
'operator ->'
D:\Projs\Libs\boost_1_46_1\boost/date_time/posix_time/posix_time_config.hpp(57)
: see
declaration of 'boost::posix_time::time_duration' did you intend to use '.'
instead?

This doesn't happen in linux version where sleep is
inline void sleep(TimeDuration const& rel_time)
        {
            this_thread::sleep(get_system_time()+rel_time);
        }
(this is the version that refused to work with
boost::this_thread::sleep(&td) as in the root post)

So right now, the code that works for both win32 and linux is
using namespace boost::posix_time;
using namespace boost::this_thread;
time_duration td = milliseconds(2000);
#ifdef _WIN32
    sleep(&td);
#else
    sleep(td);
#endif

It's probably not supposed to be like that, but this is the only way it's
working for me. If anyone could
come up with a more elegant solution, I'd appreciate it greatly.

-- 
Take care,
Alexey Malakhov