Hi,
We have some code that looks like this:
void
fileProcessorFunction ()
{
// … some implementation …
}
Later we do:
new boost::thread(fileProcessorFunction);
We found, using Intel C++ compiler v12 on Windows with boost 1.47 that our application crashed in both Debug and Release.
This constructor ends up initializing thread_info with the result of make_thread_info thus:
template <class F>
thread(F&& f) :
thread_info(make_thread_info(static_cast<F&&>(f)))
{
start_thread()
}
which maps into assembly that takes f and then dereferences it and passes it to make_thread_info so the thread_data member ends up having not the function pointer f that it should have but instead a pointer equal to the first 4 bytes of what f was pointing
at. Things go downhill from there.
We noticed that removing the static_cast (as below) resolved this issue.
template <class F>
thread(F&& f) :
thread_info(f)
{
start_thread()
}
Clearly there’s a compiler defect at play but I was wondering why the static_cast <F&&> in the first place? Does this result in a valuable optimization that’s subverted by removing it?
Thanks,
Andy