Talk About Network

Google


Register and Login
Nick
Password
Register create new account Sign up is FREE and you can post replies, new topics, bookmark posts and more!
Recover lost password


Programming > Codewarrior Windows > Re: Bug Re****t...
Latest [ Topics | Posts ] Archive Post A New Topic Post a Reply
<< Topic < Post Post 2 of 3 Topic 256 of 319
Post > Topic >>

Re: Bug Re****t: Bogus built-in operator considered during overload resolution

by Howard Hinnant <hinnant@[EMAIL PROTECTED] > Feb 19, 2005 at 04:48 PM

In article <37laceF5e4e9sU1@[EMAIL PROTECTED]
>,
 "Jonathan Turkanis" <technews@[EMAIL PROTECTED]
> wrote:

> Hi,
> 
> This is essentially a re-post of a message from a few days ago, with a
more
> eye-catching subject line.
> 
> According to section 13.6 of the standard, an operator of the form
> 
>    T& operator*(T*)
> 
> should be considered during overload resolution for an expression of the
form 
> *x
> where x has class type, only if T is a function type or an object type.
Since
> void is not an object type, the no operator of the form operator*(void*)

> should
> be considered.
> 
> However, I'm getting a complaint of ambiguity from Codewarrior 9.3 and
9.4
> relating to an expression *x, where x has type std::istream, in which
one of 
> the
> two candidate functions is described as operator*(void*). (See
> http://tinyurl.com/626kr).
> 
> The following test program is a simplification of the code which leads
to the
> above error.
> 
>     struct Thing {
>         operator void* () const;
>     };
> 
>     struct any {
>         template<class T>
>         any(T const&);
>     };
> 
>     char operator*(any const&);
> 
>     int main()
>     {
>         Thing t;
>         *t;
>     }
> 
> Any help would be greatly appreciated.

Jonathan, thank you very much for the concise bug re****t.  Our apologies 
for not getting back to you sooner. This has been forwarded to our chief 
compiler engineer, and fixed for the next release.

In the meantime, as a workaround, the only thing I'm coming up with is 
to check is_convertible<T, void*> before proceeding with the 
is_dereferenceable check.  I realize this is kind of a hack.  But 
perhaps it is better than the status quo.

Maybe something along the lines of:

#include <msl_utility>

struct any {
    template<class T>
    any(T const&);
};

char operator*(any const&);

struct two {char dummy_[2];};

namespace detail
{
template <class T>
class is_dereferenceable
{
    static typename 
Metrowerks::select<Metrowerks::is_fundamental<T>::value,
        any, T&>::type t;
    template <class U> static char test(const U&);
    template <class U> static two test(char);
public:
    static const bool value = sizeof(test<T>(*t)) == 1;
};

}  // detail

template <class T>
class is_dereferenceable
{
    template <class U> static char test(const U&);
    template <class U> static two test(char);
public:
    static const bool value = Metrowerks::_and<
        Metrowerks::_not<Metrowerks::is_convertible<T, void*> >,
        detail::is_dereferenceable<T> >::value;
};

Thanks again for the bug re****t, your perseverance, and your patience.

-Howard
 




 3 Posts in Topic:
Bug Report: Bogus built-in operator considered during overload r
"Jonathan Turkanis&q  2005-02-17 21:43:04 
Re: Bug Report: Bogus built-in operator considered during overlo
Howard Hinnant <hinnan  2005-02-19 16:48:27 
Re: Bug Report: Bogus built-in operator considered during overlo
"Jonathan Turkanis&q  2005-02-19 14:12:56 

Post A Reply:
  Go here to Signup

AddThis Feed Button


About - Advertising - Contact - Frequently Asked Questions - Privacy Policy - Terms of Use - Signup

Contact
tan12V112 Fri Jul 25 2:34:58 CDT 2008.