Frank Schönheit - Sun Microsystems Germany wrote:
Hi Rainman,
I have another ideal, it is better and safer than the last one I mentioned.
I add a conversion operator to Reference, instead of a constructor, here is it:
template < class base_interface_type >
inline SAL_CALL operator const Reference< base_interface_type > ()
const SAL_THROW( () )
{ return Reference< base_interface_type >( get() ); }
I tested some cases, and it works well.
How do you think it? I am not very sure it will work for all situation.
Uhm - implicit conversion operators are Evil (TM) :)
This is a place where my gut feeling says we should sacrifice the little
convenience we could gain (xA = xB instead of xA = xB.get()) for
clarity. At least clarity in reading code, but also clarity in reading
the error messages which the compiler would raise for incompatible xA
and xB :)
Admittedly, this feeling is not backed up by strong arguments, but I am
sure others could come up with some. Stephan
You must be very careful before introducing an implicit conversion. By
careful, I mean, you should understand the consequences.
Although conversion operators are nice for your intended purpose, they
compromise type safety and disable the compiler's type-safety checks.
For this reason, library designers usually do not include conversion
operators, even though is it inconvenient for the user; for example,
there is not a conversion operator from (const char *) to std::string
(and that feels like an obvious one to include if you ignore the side
effects).
This is a reason that it is recommended that you use the explicit
keyword before constructors that accept only one argument (because it is
used as an implicit conversion operator).
Do you need or desire examples of where this can go awry?
--
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
My Book: http://www.hentzenwerke.com/catalog/oome.htm
Info: http://www.pitonyak.org/oo.php
See Also: http://documentation.openoffice.org/HOW_TO/index.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
