void foo (const A &);
B b;
foo(b);
A & operator = (A &, const B &);
Defining implicit conversion in C++
Author
Hello everyone.
In C++, say I have two classes A and B. I can create a constructor A::A(const B&){...} or, if I cant modify the class A for some reason, I can define B::operator A()const{...}
Suppose I can't modify the class B either, but want to have a function used like this:
If I had either of the two methods defined as above, this would be fine. Can I define a conversion operator, external to both classes, which will achieve the same thing?
In my mind this isn't very different to defining so if what I'm asking is disallowed, can someone please explain the motivation?
Quote:Original post by spraff
Can I define a conversion operator, external to both classes, which will achieve the same thing?
No. Conversion operators must be internal to the class. I don't know the motivation; you'll have to ask Stroustrup.
What are you trying to accomplish? It doesn't have anything to do with integrating incompatible math libraries, does it?
Quote:Original post by spraff
In my mind this isn't very different to defining *** Source Snippet Removed ***
That isn't legal either, so I don't understand what kind of point you're making.
I'm afraid operator= can only be defined as a member function too. They probably don't want to give you the chance to modify crucial behaviour of classes from outside.
if foo can take an A, but you want to pass a B, there must be some common factor, either A and B have the same member function call, and you could template you function. or both are otherwise convertable to some third type (or have a member like .getasint() ) so why not make your function take that type instead?
If you have inheritence ( B: public A ), then you can make foo take an A* as input.
[Edited by - KulSeran on December 14, 2008 2:33:10 PM]
If you have inheritence ( B: public A ), then you can make foo take an A* as input.
[Edited by - KulSeran on December 14, 2008 2:33:10 PM]
Quote:Original post by Sneftel
No. Conversion operators must be internal to the class. I don't know the motivation; you'll have to ask Stroustrup.
It requires access to private data members, otherwise only the publics would get copied. Although, why not make a friend assignment operator... I don't really know. I suspect it's due to how he intended friend functions to be used.
Quote:Original post by visitor
I'm afraid operator= can only be defined as a member function too. They probably don't want to give you the chance to modify crucial behaviour of classes from outside.
Yeah. And, again, requires access to privates.
Implicit conversion:
class A {};class B{ operator A(); // No return type!};
Neither of those things *requires* access to private members. Offhand, every STL container I can think of can quite easily be copied using only public accessors.
Author
Quote:Original post by Sneftel
Neither of those things *requires* access to private members. Offhand, every STL container I can think of can quite easily be copied using only public accessors.
Exactly my reasoning. Suppose there were two string classes in an application, being perhaps returned from the functions of two different external (immutable) libraries. I might want to pass a string from one library as an argument to the function of another.
At the moment I would have to do something equivalent to libraryone_func(convert(library2_func())) Of couse it would be nice for this to be done implicitly. All this talk about private members is nonsense, that's what public constructors deal with.
Couldn't you use another function that wraps the call to library2_func and the convert call?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
