Fwd: strange looking ambiguity with type cast
Fwd: strange looking ambiguity with type cast
- Subject: Fwd: strange looking ambiguity with type cast
- From: Mark Lentczner <email@hidden>
- Date: Wed, 11 Feb 2004 20:14:41 -0800
I believe that gcc is correct vis-a-vis the C++ standard. Alas,
Gooch's mention of a a& through things off the track...
Let me see if I can explain this:
You write "(a)_b;"
My guess is that you expect that this says "cast _b to type a".
It does not.
What it says is: "construct an a, in a temporary auto variable,
initialized from _b".
This is an important difference. The first interpretation would indeed
only allow one sequence of calls.
However, the second interpretation (which is the C++ standard), allows
two different paths, each involving one user conversion function (one
and only one is allowed under the C++ standard). Either:
a(operator int(_b))
or a(operator a(_b))
The second makes use of the compiler generated copy constructor for a
("a(const a&)"). A common mistake in C++ is to forget that you ALWAYS
get the compiler generate copy constructor unless you declare one
yourself.
The other points you bring up:
[] No: "(a)_b;" is not equivalent to: "_b.operator a()".
[] Yes: your conversion function doesn't return a reference, but it
does require a copy constructor invocation (for a) to move the returned
value from the member function to the caller.
[] Irrelevant: Even though the generated copy constructor for a is
trivial, it still exists semantically even if the optimization phase
will remove it entirely
[] What you may have misunderstood is what the cast expression in C++
means.
[] Yes: other compilers often get this subtlety wrong wrong wrong!
- Mark "C++ Geek" Lentczner
Mark Lentczner
http://www.ozonehouse.com/mark/
email@hidden
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.