Re: [boost] [type_traits][result_of] Handling of cv-qualified functionpointers/references

From: João Abecasis (jpabecasis_at_[hidden])
Date: 2006-05-30 19:14:24

Hi!

John Maddock wrote:
> João Abecasis wrote:
>> and a slightly more convoluted for type_traits::is_pointer:
>>
>>      #include <boost/type_traits/is_function.hpp>
>>      #include <boost/static_assert.hpp>
>>
>>      void foo ();
>>
>>      template <class F>
>>      void bar(F &)
>>      {

This,

>>          BOOST_STATIC_ASSERT(boost::is_function<F const>::value);

should actually be,

         BOOST_STATIC_ASSERT(boost::is_function<F>::value);

Which means that the const function type is entirely synthesized by the 
compiler.

>>      }
>>
>>      template <class F>
>>      void baz(F const & f)
>>      {
>>          bar(f);
>>      }
>>
>>      int main()
>>      {
>>          baz(foo);
>>      }
> 
> Right that should fail because:
> 
> *There is no such thing as a const-qualified function type in the C++ 
> language*

Should this be reported as a bug in gcc 4, then?

> So argument deduction for baz would fail because it would have an invalid 
> signature.  Actually, having said that, I seem to remember that behaviour 
> may have been changed by a DR that makes a cv-qualified function type (or 
> reference) the same as the non-cv-qualified type.

I do get the argument deduction failure in baz with gcc-3.2.3 (from 
FC5). While vanilla gcc-4.0.3 and 4.1.0 result in a static assertion 
failure.

> Unfortunately this is a bug that crops up in compilers from time to time, 
> often they allow you to generate cv-qualified function or reference types 
> inadvertently, but don't let you test for them with partial specialistion 
> because that part of the compiler "knows" the situation can never occur :-(
> 
> BTW your code compiles cleanly with gcc-3.4.4 and Intel 9 and VC++8 (after 
> removing the const from the function baz).

That const is the fundamental one. The other one appeared from the lack 
of synchronization of the report with the actual test case... (Now I 
need literate programming in my e-mails too! :-) )

> I'm surprised that gcc-4 has this issue, I'm fairly sure we looked at this 
> for gcc-2 and couldn't fix it (or maybe it was the cv-qualified reference 
> issue we looked at, I don't remember now).  Whatever, if you have a patch 
> that works then yes lets fix is_function to workaround the problem for those 
> specific compilers.

The way I "solved" this for unpack_args was to apply remove_cv to the 
type before testing with is_pointer. We don't need to know if it is a 
cv-qualified function beforehand. Perhaps the same approach could be 
used in type_traits:

     template <class T>
     struct is_pointer
         : is_pointer_impl<typename remove_cv<T>::type>
     {
     };

? Admittedly this would only be enabled if and where it makes a difference.

Best regards,

João