boost::detail::heap_new does not have a variadic variant

[dean.browning@…]

Locally, we had code that previously built in CentOS 6.x, using a compiler circa from 2009 that does not support variadic templates / rvalue references:

gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18) Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Without variadic templates / rvalue references boost provides a boost::thread's variable argument constructor that supports up to 9 arguments + thread main. Sadly, the variadic implementation that is enabled when rvalue references + variadic arguments are supported is:

template<typename F, class ...ArgTypes> static inline detail::thread_data_ptr make_thread_info(BOOST_THREAD_RV_REF(F) f, BOOST_THREAD_RV_REF(ArgTypes)... args) {

return detail::thread_data_ptr(detail::heap_new<

detail::thread_data<typename boost::remove_reference<F>::type, ArgTypes...>

(

boost::forward<F>(f), boost::forward<ArgTypes>(args)...

)

);

}

In turn, this calls into the platform specific version of heap_new, which currently only supports up to a total of 4 arguments. Locally, I have modified my boost version (e.g. boost/thread/pthread/thread_heap_alloc.hpp) to have this definition:

#if defined(BOOST_THREAD_PROVIDES_VARIADIC_THREAD)

template<typename T,typename... Args> inline T* heap_new(Args&&... args) {

return new T(static_cast<Args&&>(args)...);

}

#else ...

While this is functional for my needs, obviously I think it (or something like it) should get into boost proper. Moreover, not that it likely matters, but it would also be wise to support at least 10 arguments to heap_new, in the non-variadic variant, so that it supports the ubiquity of other use cases in boost::thread et al.

A similar implementation should be provided for win32.