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.

[viboes]

Hi,

it is incredible that no one have observed this bug since the beginning.

I'll try to fix it for the next version.

[viboes]

In addition to your variadic patch I'm ready to provide the up to 9 version for

        template<typename T,typename A1,typename A2,typename A3,typename A4>
        inline T* heap_new_impl(A1 a1,A2 a2,A3 a3,A4 a4)
        {
            return new T(a1,a2,a3,a4);
        }

but not for the mix of const/non-const ref variant

        template<typename T,typename A1,typename A2>
        inline T* heap_new(A1 const& a1,A2 const& a2)
        {
            return heap_new_impl<T,A1 const&,A2 const&>(a1,a2);
        }
        template<typename T,typename A1,typename A2>
        inline T* heap_new(A1& a1,A2 const& a2)
        {
            return heap_new_impl<T,A1&,A2 const&>(a1,a2);
        }
        template<typename T,typename A1,typename A2>
        inline T* heap_new(A1 const& a1,A2& a2)
        {
            return heap_new_impl<T,A1 const&,A2&>(a1,a2);
        }
        template<typename T,typename A1,typename A2>
        inline T* heap_new(A1& a1,A2& a2)
        {
            return heap_new_impl<T,A1&,A2&>(a1,a2);
        }

Of course, a patch using preprocessor programming is welcome.

[viboes]

​https://github.com/boostorg/thread/commit/bb32aa3164c89bf882c248ff7794661f88d17768

[viboes]

​https://github.com/boostorg/thread/commit/a02f0ec577644ca45cdca20e91cd8cd82e6c2017