[Patch] libstdc++/21244

[Gabriel Dos Reis]

Paolo Carlini <pcarlini@suse.de> writes:

| Paolo Carlini wrote:
| 
| >I agree about your "hyper-panic mode" remark. Actually I was exactly
| >considering in my mind the last situation. In our current
| >cpp_type_traits we have this specific code, exploiting your nice traitor:
| >
| >  template<class _Sp, class _Tp>
| >    struct __traitor
| >    {
| >      enum { __value = _Sp::__value || _Tp::__value };
| >      typedef typename __truth_type<__value>::__type __type;
| >    };
| >
| >  template<typename _Tp>
| >    struct __is_arithmetic
| >    : public __traitor<__is_integer<_Tp>, __is_floating<_Tp> >
| >    { };
| >
| >Is this 100% safe even if the user (contra any good C++ programming book
| >advice) overloads operator|| like, in c++/19404, operator/?!?
| >  
| >
| Sigh, the below doesn't compile with 4.0 and mainline:
| 
| #include <vector>
| 
| class Foo
| {
| };
| 
| template<class T> Foo operator||(const Foo& arg1, T arg2)
| {
|   return Foo();
| }
| 
| void foo()
| {
|   std::vector<int> bar(1);
| }

See my other mail.  The issue is not the use of unnamed enumeration.
The issue is that of quantum process (overload resolution +
questionable rule in the standard).
Even if you change the enumeration to be named, you still are at the
mercy of this

  template<class T>
    typename enable_if<T, is_enum<T>::value>::type
    operator||(int a, T b) 
    { 
        return T(a || int(b)); 
    }

   std::vector<int> bar(1);

-- Gaby