Re: strange looking ambiguity with type cast
Re: strange looking ambiguity with type cast
- Subject: Re: strange looking ambiguity with type cast
- From: "Glen Low" <email@hidden>
- Date: Thu, 12 Feb 2004 02:44:40 -0500
>> uh... why? As I know it, it is generally good practice to return/pass
>> references (except to local object, of course -- which we don't have
>> in this case) to avoid a spurious copy constructor call for the
>> temporary.
>
>true enough, though my real class uses a copy-on-write scheme similar
>to what Qt does with QString, QPtrList, etc.
>
>remember that, in my original code snipet, i dont assign the value to
>anything, so there really should be no constructor called. in my view,
>this answers the next paragraph as well.
>
>> Point well taken, but until another argument is presented, I'd say its
>> a bug in your other compilers (or at least, another way of
>> interpreting the standard, but I'd say one way or another its a bug
>> somewhere).
>
>> I think the real issue is what you **WANT** to happen -- do you want
>> an 'a' created from an int or from a 'b'?
>
>as said in my comment above, i have a b that i want converted to an a.
>in my original example, {b _b ; (a) _b ;}, the only two things that
>should be called in the second statement should be the conversion
>method b :: operator a () and the destructor a :: ~a () as the
>temporary object gets destroyed. or have misunderstood temporary
>objects for years (it could be)? :)
Hmm...
1. Jean has correctly declared operator a () to return an "a" object, since this is a temporary and there's no persistent reference to it from "b".
2. Now that operator a () returns an "a" object, it must go through the copy constructor on its return. Most compilers including gcc will elide the copy constructor, simply constructing the "a" object "in place". However to be legitimate, the compiler *must* consider the effects of the copy constructor e.g. if it is private, it will not work.
3. That means as Gooch said, there are now two paths to a:
b.operator a () -> a (const a&)
b.operator int () -> a (int)
Jean has to pick one by preventing one path or the other, as Gooch said, by making a (int) explicit etc.
4. Current C++ thinking deprecates the use of user-defined conversions (either the converting operator or the converting constructor), for precisely these kinds of reasons. They will also mess up regular function overloading. So think carefully about why you want one; conversions should happen between 99% equivalent objects, and then only from less OO to more OO:
e.g. in std::string, there is no operator char* so std::string is not automatically converted to char* (you have to use data() or c_str()). However there is a non-explicit char* constructor, so char* can be converted into a std::string.
Essentially a conversion from A to B promises that an A can be used wherever a B can be, without any loss of integrity. This is a tough promise to make, about as tough as inheritance itself!
Cheers,
Glen Low, Pixelglow Software
www.pixelglow.com
_______________________________________________
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.