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?
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_viewwas proposed … the connection betweenstringandstring_viewwas all done instring_view.string_viewhas:
- an implicit conversion from
string,- a member function
to_string, which creates a new string.I believe that this is backwards; that
string_viewshould know nothing ofstring, and thatstringshould handle the conversions between the types. Specifically,stringshould have:
- an implicit conversion to
string_view,- an explicit constructor from a
string_view.Rationale:
string_viewas a basic vocabulary type leads to additional efficiencies.…
Creating astring_viewfrom astringis cheap, hence the implicit conversion. Creating astringfrom astring_viewis not cheap, so it should be explicit.
- Support for other string types.
…
Consider outputting data from a homegrown string class …home_string. Implementingoperator<<is a fair amount of work, requiring a reasonably complete knowledge of the entireiostreams infrastructure. On the other hand, withstring_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”.