Constructor vs casting operator
https://softwareengineering.stackexchange.com/questions/269709
-
06-10-2020 - |
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?
Solution
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.
OTHER TIPS
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 betweenstring
andstring_view
was all done instring_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 ofstring
, and thatstring
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 astring
is cheap, hence the implicit conversion. Creating astring
from astring_view
is 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 entireiostream
s 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".