Constructor vs casting operator

Question

I'm programming a library (so I have complete access to all the mentioned classes). Two classes (A and B) are essentially the same and differ only by their implementation, so they can easily be converted into one another. But I'm asking myself, if converting by passing an argument of type B to one of A's constructors or by implicitly casting B into A, is preferable. Two code examples to illustrate:

Using casting:

class A
{
public:
    int c[3];
    operator B() const
    {
        //return B(...);
    }
};

class B
{
public:
    int a, b, c;
    operator A() const
    {
        //return A(...);
    }
};

Using the constructor:

class A
{
public:
    A(const B& b)
    {
        //...
    }
    int c[3];
};

class B
{
public:
    B(const A& a)
    {
        //...
    }
    int a, b, c;
};

What are the pros and cons of both approaches? Which should one use? And could there be some problems, if someone extended the library and used the explicit keyword in some of his constructors?

Answer 1

The common way to perform such conversions is through the constructor. The typecast operators are used effectively only for conversions to primitive types (and then mostly to bool or something that effectively acts like a boolean) or types that you can't add an additional constructor to.

The typecast operators have a much bigger risk of being invoked at unexpected moments than converting constructors and should generally be treated with extreme caution.

Answer 2

One instructive example of using a type conversion operator in the Standard library is the conversion from std::string to std::string_view. Consider the simple code:

std::string s("string");
std::string_view sv(s);

No constructor of std::string_view accepts std::string, and the conversion is performed with the operator

operator std::string_view<...>() const noexcept;

in the std::string class.

The motivation of this design can be found in this document (P0254R2) by Marshall Clow, which I cite below.

When string_view was proposed ... the connection between string and string_view was all done in string_view. string_view has:

• an implicit conversion from string,
• a member function to_string, which creates a new string.

I believe that this is backwards; that string_view should know nothing of string, and that string should handle the conversions between the types. Specifically, string should have:

• an implicit conversion to string_view,
• an explicit constructor from a string_view.

Rationale:

• string_view as a basic vocabulary type leads to additional efficiencies.

... Creating a string_view from a string is cheap, hence the implicit conversion. Creating a string from a string_view is not cheap, so it should be explicit.

• Support for other string types.

... Consider outputting data from a homegrown string class ... home_string. Implementing operator<< is a fair amount of work, requiring a reasonably complete knowledge of the entire iostreams infrastructure. On the other hand, with string_view, someone could write:

template<...>
ostream<...>& operator<<(ostream<...>& os, const home_string<...>& str)
{
    return os << string_view<...>(str);
}

and get all the formatting, etc. "for free".