Re: Conversion constructor vs. conversion operator
Am 13.05.2011 17:14, schrieb A. McKenney:
On May 11, 3:22 pm, Daniel Kr?gler<daniel.krueg...@googlemail.com>
wrote:
On 2011-05-11 02:13, A. McKenney wrote:
On May 9, 8:46 pm, Daniel Kr?gler<daniel.krueg...@googlemail.com>
wrote:
... in C++0x you can make such a conversion function explicit, e.g.
...
Unless I'm missing something, this has to
be invoked by an explicit cast, which defeats
the whole rationale for having operator<type>
in the first place.
You are mistaken. When explicit conversion functions where introduced,
the core language also added a new term "contextually converted to bool"
which is true for some expression e, iff the declaration
bool t(e);
is well-formed....
It sounds like you are saying that this is
(a) a special case for "explicit operator
bool()", or maybe
(b) a special case for conversion operators
to built-in types implicitly convertable
to bool (which IIRC is all built-in scalar
types), or even
(c) a special case for conversion operators
to any type that is implicitly
convertable to bool.
(not sure which.)
Would this apply to other
"explicit operator<type>()"
conversion operators?
I agree that my reply was a bit misleading (and contained an error in
regard to the switch case, thanks to S.K. for pointing this out). Since
you were still examining on static_cast<bool>( ptr ) and isValid, which
are only conversions to bool, the references to the core language where
important in this context. Thus, the explicit conversion to bool case is
especially advantageous, because they are often used in scenarios like
if statements. I wouldn't go so far to say that an explicit conversion
function to bool is the only use-case for explicit conversion functions.
E.g. the following example also takes advantage of the core rule changes:
struct S {
explicit operator int() const { return 1; }
};
int main() {
S s;
if (s) ; // OK
}
The core rule changes just ensure that there are more reasonable support
for explicit conversions. Since they will be considered in
direct-initialization contexts they allow for symmetric conversions
among types that should not be implicit, e.g.
struct A { [..] }; // Not a class where I can change the code
This class is not aware of some other class B, but I would like for
explicit conversions. So I could add an explicit conversion function
*and* a non-converting constructor in B:
#include "A.h" // Makes definition of A available
struct B {
[..]
explicit B(A);
explicit operator A() const;
};
This allows symmetric conversions, but still reduced to the context of
direct-initialization situations
A make_A();
B make_B();
A a(make_B()); // OK
B b(make_A()); // OK
In other words: I'm not arguing about explicit conversions to bool but
about explicit conversions to any type: A simple formula is that they
are used in direct-initialization situations and that if-statement
conditions as well as some other locations mentioned in my first reply
are considered as "direct-initialization" contexts as well.
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]