GotW #19 Automatic Conversions
著者：Herb Sutter
翻译：K ][ N G of @rk™
[声明]：本文内容取自www.gotw.ca网站上的Guru of the Week栏目，其著作权归原著者本人所有。译者kingofark在未经原著者本人同意的情况下翻译本文。本翻译内容仅供自学和参考用，请所有阅读过本文的人不要擅自转载、传播本翻译内容；下载本翻译内容的人请在阅读浏览后，立即删除其备份。译者kingofark对违反上述两条原则的人不负任何责任。特此声明。
Revision 1.0
Guru of the Week 条款19：自动转换
难度：4 / 10
（从一种型别到另一种型别的自动转换有时是极度方便的。本期GotW通过一个典型的例子说明为什么自动转换同时也是极度危险的。）
[问题]
标准的string不具有向const char*进行自动转换的能力。它应该有吗？
* * * * *
[背景]：把string作为C风格的const char*来进行访问，经常是很有用的。实际上，string也确有一个成员函数c_str()专门用来完成这个任务——该函数返回const char*。下面的代码体现出两者的区别：
string s1("hello"), s2("world"); strcmp( s1, s2 ); // #1 (错误) strcmp( s1.c_str(), s2.c_str() ) // #2 (ok)如果能做到#1就再好不过了，但#1却是错误的，因为strcmp需要的是两个指针，而string和const char*之间却不存在自动转换。#2是正确的，但却因为要显式的调用c_str()而使代码变长。如果我们能使用#1难道不是更好一些吗？
[解答]
标准的string不具有向const char*进行自动转换的能力。它应该有吗？
不，理所不该。避免编写自动转换几乎总是一个可取的办法，不管是以转换运算符编写还是以single-argument non-explicit constructor（单引数非显式构造函数）编写。[注1]
说隐式转换一般是不安全的，有两个主要原因：
a) 它会影响重载解析（overload resolution）；并且
b) 它会使“错误的”代码被不声不响的编译通过。
如果存在一个从string到const char*的自动转换，那么这个转换动作将会在任何编译器认为需要的地方被调用。这便意味着，你会遇到各种各样的转换问题——与你在采用non-explicit转换构造函数时所遇到的问题是一样的。你将会很容易的写出看上去正确而实际上不正确的代码，这些代码原则上应该导致失败，但却可能由于古灵精怪的巧合而被编译通过并完成了与预期完全不同的操作。
有很多这样的例子。下面就是一个简单的例子：
string s1, s2, s3; s1 = s2 - s3; // 欧噢，或许原本是想要"+"其中的减法毫无意义，应该是错误的。然而，如果存在从string到const char*的隐式转换，那么这段代码就会被编译通过，因为编译器会不声不响的将两个string转换为const char*，然后对两个指针施以相减操作。
摘自GotW编码标准，作为小结：
——避免编写转换运算符（Meyers96: 24-31; Murray93: 38, 41-43; Lakos96: 646-650）
[注1]：这里我所关注的是隐式转换的普遍问题；其实关于「为什么string class不应该具有向const char*的转换」这个问题，还有其它一些原因。这儿有几个进一步讨论该内容的参考：
Koenig97: 290-292
Stroustrup94 (D&E): 83
[部分参考]
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
（完）
