Conversion Constructor vs Conversion Operator

More on why implicit cast operators are a bad idea.
http://www.ubookcase.com/book/Addison.Wesley/CPP.Coding.Standards.101.Rules.Guidelines.and.Best.Practices/0321113586/ch40.html

Example 1: Overloading. Say you have a Widget::Widget( unsigned int ) that can be invoked implicitly, and a Display function overloaded for Widgets and doubles. Consider the following overload resolution surprise:
 
void Display( double );             // displays a double
void Display( const Widget& );      // displays a Widget
 
Display( 5 );                       // oops: creates and displays a Widget
 
 
 
Example 2: Errors that work. Say you provide operator const char* for a String class:
 
class String {
  // &
public:
  operator const char*();          // deplorable form
};
 
 
 
Suddenly, a lot of silly expressions now compile. Assume s1, s2 are Strings:
 
int x = s1 - s2;                // compiles; undefined behavior
const char* p = s1 - 5;         // compiles; undefined behavior
p = s1 + '0';                   // compiles; doesn't do what you'd expect
if( s1 == "0" ) { ...}          // compiles; doesn't do what you'd expect
 
 
 
The standard string wisely avoids an operator const char* for exactly this reason.

@evilrix
>> I'd strongly recommend you remove the cast operator and use an explicit function call instead.

In my actual case I have in essence removed the the conversion operator by making it private and use and external global friend function to explicitly call it when needed.

The problem, however, is that I would expect the compiler to default to the conversion constructor since the conversion operator is now private. But the compiler is telling me that the conversion operator function is private an generating an error instead.

class Second; // forward declare
 
class First
{
   public:
      First();
      First(const Second&);
      // other constructors and member functions
 
   private:
      //class data
};
 
 
class Second
{
   public:
      Second();
      // other constructors and member functions
 
   private:
      //class data
      operator First() const;
 
   template <class T, class U> friend U typeConvert(T);
};
 
 
void myFunction(First obj)
{
   //do something
}
 
 
template <class T, class U>
U typeConvert(T obj)
{
   return obj.operator U();
}
 
 
#define type_convert(TYPE, VAL) typeConvert<TYPE>(VAL)
 
int main()
{
   Second item;
   
   myFunction(item);  //should call conversion constructor
   
   type_convert(FIRST, item); //should call conversion operator
   
   return 0;
}
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:

whether a member function is private or not doesn't matter for overload resolution. And the same ambiguity I mentioned in my previous post exists here too.

The compiler doesn't know what you're trying to do, so it makes a guess, which is apparently the "wrong" one (ie. not the one you wanted). You need to be a bit more explicit/unambiguous when talking to the compiler ;)

Ok. Understood.

So say I do replace the conversion operator with an regular member function, how do I overload it to get the appropriate return type where some return types are known and others aren't?

Would something like the attached code snippet work?

class Second; // forward declare
 
class First
{
   public:
      First();
      First(const Second&);
      // other constructors and member functions
 
   private:
      //class data
};
 
 
class Second
{
   public:
      Second();
      // other constructors and member functions
 
   private:
      //class data
      
      //conversion function
      template <class T>
      T convert() const;
 
   template <class T, class U> friend U typeConvert(T);
};
 
template <class T>
T Second::convert() const
{
   //error throw exception
}
 
template<>
First Second::convert<First>() const
{
   //convert and return
}
 
 
void myFunction(First obj)
{
   //do something
}
 
 
template <class T, class U>
U typeConvert(const T& obj)
{
   return obj.convert<U>();
}
 
 
#define type_convert(TYPE, VAL) typeConvert<TYPE>(VAL)
 
int main()
{
   Second item;
   
   myFunction(item);  //should call conversion constructor
   
   type_convert(FIRST, item); //should call conversion operator
   
   return 0;
}
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:

You can't overload functions on their return type, so no :)

You could however make the conversion functions take a parameter, and convert in the "other direction", as shown below.

It's cleaner this way, since you don't have to give the outside world access to the internals of the Bar class.

You probably also want to follow evilrix's advice not to use any converting constructors either (except maybe for explicit ones, but even then I wouldn't).

class Foo;
 
class Bar {
  public :
    void convert(const Foo&);   // fill the current Bar object by converting from the Foo object passed by reference
};

                                              

1:
2:
3:
4:
5:
6:

>> The problem, however, is that I would expect the compiler to default to the conversion constructor since the conversion operator is now private. But the compiler is telling me that the conversion operator function is private an generating an error instead.

Like I said before, the cast operator works in ways that are both unintuitive and often surprising. In the end all it saves you is a little bit of typing yet it introduces ambiguities in your code that is often hard to spot or predict. It's your code and you are free to choose your own coding standards but the cast operator has widely accepted to be a good example of just because you can do something it doesn't mean you should.

That all said, the reason your code above doesn't build is because your template parameters were wrong. You were using T and U the wrong way around.

class Second; // forward declare
 
class First
{
   public:
      First(){}
      First(const Second&){}
      // other constructors and member functions
 
   private:
      //class data
};
 
 
class Second
{
   public:
      Second(){}
      // other constructors and member functions
 
   private:
      //class data
      operator First() const { return First(); }
 
   template <class T, class U> friend T typeConvert(U);
};
 
 
void myFunction(First obj)
{
   //do something
}
 
 
template <class T, class U>
T typeConvert(U obj)
{
   return obj.operator T();
}
 
 
#define type_convert(TYPE, VAL) typeConvert<TYPE>(VAL)
 
int main()
{
   Second item;
   
   myFunction(item);  //should call conversion constructor
   
   type_convert(First, item); //should call conversion operator
   
   return 0;
}
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:

>> That all said, the reason your code above doesn't build is because your template parameters were wrong. You were using T and U the wrong way around.

The ambiguity is still there though ;)

>> The ambiguity is still there though ;)
I agree... I don't advocate this code be used... but the actual error as the code stands was related to the template definition being incorrect... I am with you 100% on this :)

>> The ambiguity is still there though ;)

Meaning that for a strictly conforming compiler, it will still not compile.

>> I am with you 100% on this :)

And I with you ;)

Although my problem hasn't been completely resolved, the question as posed has been answered. As such I am obliged to mark the question as answered and award points. Well done.

>> Although my problem hasn't been completely resolved

We're still here to help you out with the part of your problem that hasn't been resolved yet. Just tell us what it is :)

>>>> I don't advocate this code be used...
Yes, it contradicts the first recommendation that cast operators shouldn't be used. Moreover, a template function should spare code by using the same functional body for all types. If a template function is depending on existing cast operators which provide individual code for each type, it isn't much more than shadowboxing.

You should provide member functions First::fromSecond(const Second & s) or a global function like secondToFirst(const Second & s, First & f) to get a clear and easy-to-understand interface rather than to rely on implicit conversions.

>>>> This is why the standard STL string has a c_str() member rather than a operator const char *().
Actually, this is the only sample where I miss the cast operator known from other string classes. As it is a cast to a const type (const char *) possible side effects would be small and IMO could be neglected.

>> As it is a cast to a const type (const char *) possible side effects would be small and IMO could be neglected.
It has nothing to do with constness. Look at the following examples by Alexandrescu...

int x = s1 - s2;                // compiles; undefined behavior
const char* p = s1 - 5;         // compiles; undefined behavior
p = s1 + '0';                   // compiles; doesn't do what you'd expect
if( s1 == "0" ) { ...}          // compiles; doesn't do what you'd expect

...none of these are as a result of constness or otherwise.
 

I replaced the cast operator with a convert function and it works generally as code in the code snippet. However, I have to make the convert function public and comment out the global typeConvert function.

Whenever I compile using the global typeConvert function I get a compiler error:

      error C2440: 'initializing' : cannot convert from 'Second' to 'First'

what am I doing wrong?

class Second; // forward declare
 
class First
{
   public:
      First();
      First(const Second&);
      // other constructors and member functions
 
   private:
      //class data
};
 
 
class Second
{
   public:
      Second();
      // other constructors and member functions
 
   private:
      //class data
      
      //conversion function
      template <class T>
      T convert() const;
 
   template <class T, class U> friend U typeConvert(T);
};
 
template <class T>
T Second::convert() const
{
   //error throw exception
}
 
template<>
First Second::convert<First>() const
{
   //convert and return
}
 
 
void myFunction(First obj)
{
   //do something
}
 
 
template <class T, class U>
U typeConvert(const T& obj)
{
   return obj.convert<U>();
}
 
 
#define type_convert(TYPE, VAL) typeConvert<TYPE>(VAL)
 
int main()
{
   Second item;
   
   myFunction(item);  //should call conversion constructor
   
   type_convert(FIRST, item); //should call conversion operator
   
   return 0;
}
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:

correction: i was trying to transpose the the error message didn't do too well. It should be more like cant convert from 'Second' to 'Second*' or 'Second&'

It seems to me you're making things way more complicated than they need to be.

How about just implementing the convert function I showed in http:#25155873, and call that whenever you need to convert from Foo to Bar ? And get rid of all converting constructors and cast operators.

Ok I get what you saying...thanks

>>>> Look at the following examples by Alexandrescu...

Bad samples. If you have a cast operator turning an object to a pointer, it necessarily is the chance that pointer  arithmethics go wrong, but if you do such kind of programming things go wrong anyway ...

The last sample definitively is false for CString class and my own various string classes which all had a cast operator for const char* but also an operator== which take a const char * as right operand and a global operator which takes a const char* as left operand and a string class object as right operand. Given those operators the compilers I used never made a cast but use the correct operator==.

Same applies for the third sample. If an operator+ exists which takes a right hand char operand, the right term correctly would use the operator+.  The flaw is that such a temporary shouldn't be assigned to a pointer.  But those bads can be done without cast operators as well:

  string str = "Hello";
  const char * p = (str + 'a').c_str();

>>>> ...none of these are as a result of constness or otherwise

Yes because they were bad samples.

A really pitfall could (only) occur if you provide a cast to a non-const pointer as it may destroy the internal buffer or writes out of boundaries.

>>>> How about just implementing the convert function I showed in http:#25155873, and call that whenever you need to convert from Foo to Bar ? And get rid of all converting constructors and cast operators.
>>>> Ok I get what you saying...thanks

If so, you did choose the wrong answer of Infinity as an assist.

Ok Alex, you clearly know more than one of the words leading experts on C++.
http://en.wikipedia.org/wiki/Andrei_Alexandrescu