Re: Conversion constructor vs. conversion operator
"Jeffrey Schwab" <jeff@schwabcenter.com> schrieb im Newsbeitrag
news:fb8a16ec-ccf3-4a2c-b8b3-a99744bd3858@glegroupsg2000goo.googlegroups.com...
On Monday, May 2, 2011 3:22:39 PM UTC-4, Matthias Hofmann wrote:
I was wondering whether there are any general guidelines as to when a
class
should define a conversion operator rather than conversion constructor?
There is almost never a good reason to provide implicit conversion
operators; always prefer conversion constructors. The only common
exception to this rule is provide a conversion to a boolean type, so that
objects (e.g., smart pointers) can be used in boolean contexts.
So a conversion constructor should be provided if *explicit* conversion is
wanted, with the constructor declared as "explicit", while an conversion
operator is meant to enable *implicit* conversion. I think that's a good
rule of thumb and justifies the following member function template typically
found in smart pointers to enable implicit inheritance based type
conversion:
template <typename T>
class SmartPtr
{
T* m_ptr;
public:
template <typename U>
operator SmartPtr<U>()
{
return SmartPtr<U>( m_ptr );
}
};
I know that you do not always have a choice, for example, you need a
constructor to convert *from* a built-in type and you need an operator to
convert *to* a built-in type.
You do not need such an operator. Make the conversions explicit, or allow
implicit conversion to your UDT of any objects of built-in type (in mixed
expressions).
But then I have to implement operator+() and many other operators used in
mixed expressions for my UDT. Wouldn't it be easier to simply convert my UDT
to a built-in type and have the compiler use the built-in operators?
Besides, what if I need to pass my UDt to a function that takes a built-in
type as an argument?
But what about converting between user-defined types? std::auto_ptr
defines
both a conversion constructor and a conversion operator, but is this
always
necessary?
No. auto_ptr is broken. It wants a move constructor, but the language
could not provide one at the time the class was written. If neither UDT
knows about the other, either escalate one to "dominate" the other (i.e.,
to know about, and provide implicit conversion from and explicit
conversion to, the dominated type), or provide a third, higher-level
utility for performing the conversions. There's a chapter about this in
Large Scale C++ Design by John Lakos.
I understand the basic concept of a moving constructor, but I don't know how
the upcoming C++ standard is going to provide special support for this. I
hope it's not going to get complicated? Sometimes it already seems hard for
me to catch up with all the present features, one day I understand how it
works, the next day it's deprecated...
And how do I prevent ambiguities when the compiler has to choose
between a constructor and an operator to perform a conversion?
Don't define implicit conversion operators, except to some hard-to-abuse
type used strictly in boolean contexts (e.g., pointer to private member).
You mean something like this?
class MyClass
{
int* m_ptr;
public:
operator bool()
{
return m_ptr != NULL;
}
};
--
Matthias Hofmann
Anvil-Soft, CEO
http://www.anvil-soft.com - The Creators of Toilet Tycoon
http://www.anvil-soft.de - Die Macher des Klomanagers
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]