# Defining implicit conversion in C++

This topic is 3475 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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:
void foo (const A &);
B b;
foo(b);


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
A & operator = (A &, const B &);


so if what I'm asking is disallowed, can someone please explain the motivation?

##### Share on other sites
Quote:
 Original post by spraffCan 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?

##### Share on other sites
Quote:
 Original post by spraffIn 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.

##### Share on other sites
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.

##### Share on other sites
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]

##### Share on other sites
Quote:
 Original post by SneftelNo. 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 visitorI'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.

Implicit conversion:
class A {};class B{    operator A(); // No return type!};

##### Share on other sites
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.

##### Share on other sites
Quote:
 Original post by SneftelNeither 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.

##### Share on other sites
Couldn't you use another function that wraps the call to library2_func and the convert call?

1. 1
2. 2
3. 3
4. 4
Rutin
17
5. 5

• 11
• 21
• 12
• 11
• 41
• ### Forum Statistics

• Total Topics
631401
• Total Posts
2999871
×