RE: Ambiguous conversions
RE: Ambiguous conversions
- Subject: RE: Ambiguous conversions
- From: "Bill Lowrey" <email@hidden>
- Date: Fri, 23 Jun 2006 13:05:21 -0500
- Organization: istation
This is a guess, but it might be that you have defined the parameter for the
operator[] to be a long, not an int. To test this assumption, try the
following change:
int main(void)
{
long idx = 2L;
MString str("test", 5);
return str[ idx ]; // <-- Error occurs here
}
If that works, you might try changing the index parameter to an int, unless
you really need it to be a long, which I would question...
Bill
-----Original Message-----
From: xcode-users-bounces+billl=email@hidden
[mailto:xcode-users-bounces+billl=email@hidden] On Behalf Of
Mark Wagner
Sent: Friday, June 23, 2006 12:34 PM
To: Laurence Harris
Cc: Xcode Users
Subject: Re: Ambiguous conversions
On 6/22/06, Laurence Harris <email@hidden> wrote:
>
> On Jun 22, 2006, at 6:50 PM, Mark Wagner wrote:
>
> > Since converting a project from CodeWarrior to XCode, the compiler's
> > been notifying me about ambiguous conversions.
> >
> > Example code (oFileName is a MFileName object, derived from the
> > MString class):
> > if('.' == oFileName[i])
> >
> > The message:
> > ISO C++ says that these are ambiguous, even though the worst
> > conversion for the first is better than the worst conversion for the
> > second:
> > ../MODEL/MString.h:148: note: candidate 1: const wchar_t&
> > MString::operator[](long int) const
> > /DEVELOPMENT xcode/TGEQ/TGEQ.prj/../MODEL/MEXAM.CPP:254: note:
> > candidate 2: operator[](const wchar_t*, int) <built-in>
> >
> >
> > Under CodeWarrior, these didn't even generate a warning. Under Xcode
> > 1.5/gcc 3.3, the compiler gave a warning, but compiled anyway. Xcode
> > 2.3/gcc 4.0 gives an error: "ISO C++ says that these are ambiguous,
> > even though the worst conversion for the first is better than the
> > worst conversion for the second". Should I be worried that attempting
> > to compile this under XCode 2.5/gcc 4.1 will cause my computer to
> > explode?
> >
> > More seriously, how do I solve this? Is there something I can change
> > in the function prototype, or do I need to go through the code and
> > change the thousands of lines that trigger this error?
>
> I am a fanatical user of named constants, so I have this in a header
> that's included in my pch:
>
> const
> UniChar kPeriod = 0x002EU;
>
> I do this since everything *I* do with character constants like this
> involves working with UTF-16 characters, so no conversions are required.
It's not the constant that's the problem. Here's a code sample that
demonstrates what's going on:
class MString
{
public:
MString( const char* str , long length );
operator const char*( void ) const;
operator const wchar_t* (void ) const;
operator const unsigned char*( void ) const;
const wchar_t& operator[]( long index ) const;
};
int main(void)
{
MString str("test", 5);
return str[2]; // <-- Error occurs here
}
Is there any way to fix this, preferably without removing the
typecasts from the class, and without changing the 1,800 lines of code
where the error is occuring? Say, with a minor tweak to the class, or
by telling the compiler to go back to its old behavior?
--
Mark Wagner
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden