Gotw # 19 Automatic Conversions
Author: Herb Sutter
Translation: k] [N g of @ rkTM
[Declaration]: This article takes the Guru of The Week column on www.gotw.ca website, and its copyright belongs to the original person. Translator Kingofark translated this article without the consent of the original person. This translation is only for self-study and reference, please read this article, do not reprint, spread this translation; people download this translation content, please delete its backup immediately after reading. Translator Kingofark is not responsible for people who violate the above two principles. This declaration.
Revision 1.0
GURU Of The Week Terms 19: Automatic Conversion
Difficulty: 4/10
(From a type to another type of automatic conversion is sometimes extremely convenient. This period of GOTW illustrates why automatic conversion is also extremely dangerous.)
[problem]
Standard String does not have the ability to convert to const char *. Should it be?
* * * * *
[Background]: Access String as a C style const char * is often useful. In fact, String also has a member function c_str () specifically used to complete this task - the function returns const char *. The following code reflects the difference between the two:
String S1 ("Hello"), S2 ("World");
STRCMP (S1, S2); // # 1 (error)
STRCMP (S1.C_STR (), S2.C_STR ()) // # 2 (ok)
If you can do # 1, it is better, but # 1 is wrong, because StrCMP needs two pointers, and there is no automatic conversion between String and Const char *. # 2 is correct, but because the code becomes longer because of the explicit calls C_STR (). If we can use # 1 isn't it better?
[answer]
Standard String does not have the ability to convert to const char *. Should it be?
No, it should not be. Avoid writing automatic conversion almost always a need, whether in writing or by the conversion operator or by Single-Argument Non-Explicit Constructor (single number non-display constructor). [Note 1]
Saying implicit conversions is generally unsafe, there are two main reasons:
a) it will affect overload resolution; and
b) It will cause "wrong" code to pass the compilation.
If there is an automatic conversion from String to const char *, then this conversion action will be called in any compiler that is considered to be needed. This means that you will encounter a variety of conversion problems - the problem that you encounter with you when using a Non-Explicit conversion constructor. You will easily write code that looks correct and actually incorrect. These codes should cause failure, but it may be compiled by the ancient spirits coincidence and completed with expected operations.
There are many examples. Below is a simple example:
STRING S1, S2, S3;
S1 = S2 - S3; // Europe, maybe it is " "
The subtraction is meaningless, it should be wrong. However, if there is an implicit conversion from String to const char *, this code will be compiled because the compiler will not sound into const char *, and then apply to two pointers Decrease operation.
From the GOTW coding standard, as a summary: - Avoid writing a conversion operator (Meyers96: 24-31; Murray93: 38, 41-43; Lakos96: 646-650)
[Note 1]: Here I am paying attention to the universal problems of implicit conversion; in fact, "why String Class should not have the conversion to const char *", there are other reasons. There are several references to this content here:
Koenig97: 290-292
Stroustrup94 (D & E): 83
[Part of reference]
Koenig97 Andrew Koenig.
"Ruminations on C "
Addison-Wesley, 1997
Lakos96 john lakos.
"Large-Scale C Software Design"
Addison-Wesley, 1996
MEYERS96 Scott Meyers.
"More Effective C "
Addison-Wesley, 1996
Murray93 robert murray.
"C Strategies and Tactics"
Addison-Wesley, 1993
Stroustrup94 bjarne stroustrup.
(OR D & E) "The Design and Evolution of C "
Addison-Wesley, 1994
(Finish)
