 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Jinhao
Guest
|
 Posted: Sun Apr 25, 2004 11:09 pm Post subject: Conversion Problem |
 |
|
Hi,
I read the "C++ Primer" and I got a problem. The book says
class A{
public:
operator int();
operator float();
//...
};
void func( float );
void func( char );
int main(){
A a;
func(a);//it is ambiguous
}
the User-defined conversion sequences are:
func(float): operator float() -> Exact Match
func(char): operator int() -> Standart Conversion
Because the tow conversion sequences using the different conversion
function, so it can't be sure which function has the optimal parameter type
But there isn't any ambiguities in GCC 3.2, i think the call is func(float):
operator float();
because it is ambiguous for operator int() which matchs func(float) and
func(char), so the operator float() will be chose to match the func(float).
Am I right?
thank u in advance!!!
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Mikael Kilpeläinen
Guest
|
| Posted: Mon Apr 26, 2004 8:16 am Post subject: Re: Conversion Problem |
|
|
Jinhao wrote:
| Quote: | class A{
public:
operator int();
operator float();
//...
};
void func( float );
void func( char );
int main(){
A a;
func(a);//it is ambiguous
}
|
The call is ambiguous. If more than one implicit conversion sequences exist
from the argument to the parameter, the conversion sequence assosiated with
the parameter is so called ambiguous conversion sequence. This sequence is
considered indistinguishable from the other user-defined conversion
sequences and hence the call is ambiguous.
Mikael
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Stephen C. Dewhurst
Guest
|
| Posted: Mon Apr 26, 2004 8:19 am Post subject: Re: Conversion Problem |
|
|
On 25 Apr 2004 19:09:51 -0400, [email]cnjinhao (AT) hotmail (DOT) com[/email] (Jinhao) wrote:
| Quote: | Hi,
I read the "C++ Primer" and I got a problem. The book says
class A{
public:
operator int();
operator float();
//...
};
void func( float );
void func( char );
int main(){
A a;
func(a);//it is ambiguous
}
the User-defined conversion sequences are:
func(float): operator float() -> Exact Match
func(char): operator int() -> Standart Conversion
Because the tow conversion sequences using the different conversion
function, so it can't be sure which function has the optimal parameter type
But there isn't any ambiguities in GCC 3.2, i think the call is func(float):
operator float();
because it is ambiguous for operator int() which matchs func(float) and
func(char), so the operator float() will be chose to match the func(float).
Am I right?
|
No, in both cases a user-defined conversion is required, so both are
equally bad. Whether a predefined conversion is required after (or
before) the user-defined conversion is applied is immaterial.
Please note also that this is an "academic" problem, as it should be a
very rare case when a class requires more than one conversion
operator. As you can note, such designs often result in ambiguity,
both for the compiler and for the human reader of the code.
Steve
www.semantics.org
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Mikael Kilpeläinen
Guest
|
| Posted: Mon Apr 26, 2004 10:24 pm Post subject: Re: Conversion Problem |
|
|
Mikael Kilpeläinen wrote:
| Quote: | The call is ambiguous. If more than one implicit conversion sequences
exist
|
I used bad wording (like std). The sentence was supposed to mean that if two
or more conversion sequences exist and are equally good (ambiguous).
| Quote: | from the argument to the parameter, the conversion sequence
assosiated with the parameter is so called ambiguous conversion sequence.
This sequence is considered indistinguishable from the other user-defined
conversion sequences and hence the call is ambiguous.
|
Mikael
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Jinhao
Guest
|
| Posted: Wed Apr 28, 2004 12:35 am Post subject: Re: Conversion Problem |
|
|
"Stephen C. Dewhurst" <scd (AT) semantics (DOT) org> wrote
| Quote: | On 25 Apr 2004 19:09:51 -0400, [email]cnjinhao (AT) hotmail (DOT) com[/email] (Jinhao) wrote:
Hi,
I read the "C++ Primer" and I got a problem. The book says
class A{
public:
operator int();
operator float();
//...
};
void func( float );
void func( char );
int main(){
A a;
func(a);//it is ambiguous
}
the User-defined conversion sequences are:
func(float): operator float() -> Exact Match
func(char): operator int() -> Standart Conversion
Because the tow conversion sequences using the different conversion
function, so it can't be sure which function has the optimal parameter type
But there isn't any ambiguities in GCC 3.2, i think the call is func(float):
operator float();
because it is ambiguous for operator int() which matchs func(float) and
func(char), so the operator float() will be chose to match the func(float).
Am I right?
No, in both cases a user-defined conversion is required, so both are
equally bad. Whether a predefined conversion is required after (or
before) the user-defined conversion is applied is immaterial.
Please note also that this is an "academic" problem, as it should be a
very rare case when a class requires more than one conversion
operator. As you can note, such designs often result in ambiguity,
both for the compiler and for the human reader of the code.
Steve
www.semantics.org
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
Thanks a lot,
But i still wonder why the call is not a mistake though it is
ambiguous in GCC 3.2 and VC. Is it a bug of compiler or not conformed
the C++ Standard?
Jinhao
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Wed Apr 28, 2004 7:41 pm Post subject: Re: Conversion Problem |
|
|
[email]cnjinhao (AT) hotmail (DOT) com[/email] (Jinhao) wrote in message
news:<5e075a29.0404261144.2cb6c27a (AT) posting (DOT) google.com>...
| Quote: | "Stephen C. Dewhurst" <scd (AT) semantics (DOT) org> wrote in message
news:<cupo80p9806psqm02f1t3v4ff99cqkphu6 (AT) 4ax (DOT) com>...
On 25 Apr 2004 19:09:51 -0400, [email]cnjinhao (AT) hotmail (DOT) com[/email] (Jinhao) wrote:
I read the "C++ Primer" and I got a problem. The book says
class A{
public:
operator int();
operator float();
//...
};
void func( float );
void func( char );
int main(){
A a;
func(a);//it is ambiguous
}
the User-defined conversion sequences are:
func(float): operator float() -> Exact Match
func(char): operator int() -> Standart Conversion
Because the tow conversion sequences using the different
conversion function, so it can't be sure which function has the
optimal parameter type
But there isn't any ambiguities in GCC 3.2, i think the call is
func(float): operator float();
because it is ambiguous for operator int() which matchs
func(float) and func(char), so the operator float() will be chose
to match the func(float). Am I right?
No, in both cases a user-defined conversion is required, so both are
equally bad. Whether a predefined conversion is required after (or
before) the user-defined conversion is applied is immaterial.
Please note also that this is an "academic" problem, as it should be
a very rare case when a class requires more than one conversion
operator. As you can note, such designs often result in ambiguity,
both for the compiler and for the human reader of the code.
Thanks a lot,
But i still wonder why the call is not a mistake though it is
ambiguous in GCC 3.2 and VC. Is it a bug of compiler or not conformed
the C++ Standard?
|
According to the standard, the call is ambiguous. An error is
required. If the compiler doesn't generate one, it isn't conforming.
There was some fine tuning on overload resolution during
standardization. Your book ("The C++ Primer") predates the standard;
Lippman may be accurately describing overload resolution at the time.
Also, it is possible that some compilers still accept such code, in
order to avoid breaking existing code (although it would surprise me if
this were consciously the case for g++ -- they usually seem to go out of
their way to break existing code).
--
James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
