Le 08/04/12 17:18, Jeffrey Lee Hellrung, Jr. a écrit :
On Sun, Apr 8, 2012 at 5:46 AM, Vicente J. Botet Escriba
mailto:vicente.botet@wanadoo.fr> wrote: Le 07/04/12 11:11, John M. Dlugosz a écrit :
On 4/6/2012 11:59 AM, Vicente J. Botet Escriba wrote:
As you are using std::move, &&, ... why not using directly the C++11 Thread library provided with the compiler?
1) VS10 has && and std::move, but does not have the C++11 threading library. 1b) A naive implementation (just starts a new OS thread) is not wanted. 1c) but, an overly heavy implementation is not wanted either (i.e VS11 beta), because of additional dependencies in the program to distribute. 2) In the final code, the && will be optional, to avoid copies on compilers that support it, but must work with compilers that don't. 3) I need to preserve semantics of the code I'm replacing with modern C++ forms.
OK, I see.
BTW, Boost.Thread could not implement async using Boost, as Boost.Tuple, Boost.Bind Boost.Fusion (Tuple) because these libraries dont manage with rvalue references.
I don't understand how that applies to my compiler problem. It's telling me that
task_object(F const& f_); // << refers to look here task_object(F&& f_); // <<<< Error here
are not a valid overloading set and instead conflict.
Sorry, I misunderstood your message.
After applying the following patch your example compiles. Please could you try it?
Could you also add a Trac ticket so that this is tracked?
HTH, Vicente
Vicente,
It looks like you're just removing the task_object::task_object(F const &) overload. Seems strange that this overload existed but was/is never actually suppose to be used. ...except when F is a function pointer, I guess???
I sent a message to the list recently observing that one problem was the binding of F to be an lvalue reference (according to the error message, AFAICS), meaning that "F const &" and "F&&" are exactly the same type. Perhaps this behavior should be addressed directly?
After the commit some error have appeared on the regression test (see
below). It seems that the rvalue reference semantic has changed a lot
for gcc. I will try to use the last design for this compiler version.
Then I'll see what needs to be done for other compilers as soon as
results appear on the regression tests page.
Best,
Vicente
Test output: Sandia-gcc-4.3.4_0x - thread - test_4521 / gcc-4.3.4_0x
Rev 77845 / Mon, 9 Apr 2012 05:37:45 +0000
*Report Time: *Mon, 9 Apr 2012 15:38:34 +0000
Compile [2012-04-09 06:09:04 UTC]: fail
"/sierra/Sntools/extras/compilers/gcc-4.3.4/bin/g++" -ftemplate-depth-128 -std=gnu++0x -O0 -fno-inline -Wall -pedantic -g -pthread -fPIC -Wextra -Wno-long-long -pedantic -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -I".." -c -o "/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_4521.test/gcc-4.3.4_0x/debug/threading-multi/test_4521.o" "../libs/thread/test/test_4521.cpp"
../boost/thread/future.hpp: In constructor ???boost::packaged_task<R>::packaged_task(R (*)()) [with R = int]???:
../libs/thread/test/test_4521.cpp:9: instantiated from here
../boost/thread/future.hpp:1830: error: call of overloaded ???task_object(int (*&)())??? is ambiguous
../boost/thread/future.hpp:1705: note: candidates are: boost::detail::task_object