Sign in to follow this  
spraff

Defining implicit conversion in C++

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 this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
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 this post


Link to post
Share on other sites
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!
};

Share this post


Link to post
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 this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this