4

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?

  • 1
    Use the constructor. Implicit casts are the worst. I'm yet to see a good use-case for them. – Benjamin Hodgson Jan 11 '15 at 12:31
  • Thanks for your answer, Benjamin! At the moment I'm 'tending' (well, i already did it that way) to implement it as a constructor, too, but maybe there is a 'non-plus-ultra' reason, to use an implicit cast overload as well... – Benjamin Rickels Jan 11 '15 at 13:37
2

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.

3

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".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.