Boost C++ Libraries: Ticket #9338: VS2005 compiler errors in swap() definition after including container/memory_util.hpp

Fri, 15 Nov 2013 08:22:38 GMT

You get the same problem with VS2008 for both boost 1.54.0 and 1.55.0

I use <boost/container/string.hpp> and it will include both <container/detail/memory_util.hpp> and <intrusive/detail/memory_util.hpp>

Another third party library I use also defines 'swap' in the global namespace. This is quite a headache since I cannot modify the code in either boost or the other third party library.

Ion Gaztañaga — Sat, 16 Nov 2013 21:53:34 GMT

Thanks for the report. I've tried to find a workaround with no luck. It's definitely a bug in the compiler, a really strange one. If your swap function is declared in a namespace the error disappears. The bug is present at least from Visual 2003.

The error is triggered from boost/intrusive/detail/has_member_function_callable_with.hpp, which produces (for swap) the code

template< class F

, std::size_t N = sizeof((boost::move_detail::declval<F>().swap (), 0))>

struct zeroarg_checker_swap

This ".swap()" call in the sizeof expression to use SFINAE to detect if the expression is correct seems to provoke the error. Sadly, I haven't found any workaround.

Sun, 17 Nov 2013 09:43:59 GMT

Could you explain, please, why zero arguments case is handled specially? I modified it to use the same ideas an in funwrap and it seems acting perfectly without any compiler errors. That's how it looks like after preprocessing:

         template<typename Fun>
         struct funwrap0_swap
            : Fun
         {
            funwrap0_swap();
            using Fun::swap;
            boost_intrusive_has_member_function_callable_with::private_type
               swap()  const;
         };
         template<typename Fun>
         struct has_member_function_callable_with_swap_impl
            <Fun, true
            , void
            >
         {
            typedef funwrap0_swap<Fun>
                     FunWrap;
            static bool const value =
            (sizeof(boost_intrusive_has_member_function_callable_with::no_type) ==
               sizeof(boost_intrusive_has_member_function_callable_with::is_private_type
                        (  (boost::move_detail::declval<FunWrap>().
                              swap(), 0
                           )
                        )
                     )
            );
         };

For me the only worrying thing is using std::swap statement, as I don't get how exactly should this be regarded by compiler if no swap is available in Fun base class.

Ion Gaztañaga — Sun, 17 Nov 2013 13:16:49 GMT

If the template argument "Fun" has a member swap defined as:

struct Func
{
  void swap() const
  {}
};

Then the trait would lie and it would tell us that such member does not exist (the wrapper is a derived class that hides the base method). If you replace

boost_intrusive_has_member_function_callable_with::private_type swap() const;

with (variadic version)

boost_intrusive_has_member_function_callable_with::private_type swap(...) const;

then a compilation error would be triggered as

boost::move_detail::declval<FunWrap>().swap()

would be ambiguous (the compiler does not know if the variadic version from the wrapper or the base zero argument version should be called.

In non-zero argument cases, a special argument "dont_care" is used generated a very different member overload. If that is selected, then the member does not exist. With 0 arguments, this is not possible.

Ion Gaztañaga — Sun, 17 Nov 2013 13:20:42 GMT

A workaround is to tweak "boost/intrusive/detail/has_member_function_callable_with.hpp" to support non-zero lower bound values. Until now, are traits are generated from 0 to N arguments, but many of them don't need 0 arguments. "swap" is one of them (we are looking for "T::swap(T&)", no "T::swap()"). This would also generate less preprocessed code.

Other member names are likely to be less used in the global namespace than "swap", so let's see if this can at least minimize the compiler bug effects.

status changed; resolution set

Ion Gaztañaga — Mon, 18 Nov 2013 09:32:45 GMT

status new → closed
resolution → fixed

(In [86748]) Fixes #9338