Item 39. Automatic Conversions

本文探讨了C++标准库中string类型不提供隐式转换为const char*的原因,并通过实例说明了这种转换可能带来的问题,强调了避免编写隐式转换的重要性。

Automatic conversions from one type to another can be extremely convenient. This Item covers a typical example to illustrate why they're also extremely dangerous.

The standard C++ string has no implicit conversion to a const char*. Should it?

It is often useful to be able to access a string as a C-style const char*. Indeed, string has a member function c_str() to allow just that, by giving access to a const char*. Here's the difference in client code:

string s1("hello"), s2("world"); 
strcmp( s1, s2 );                // 1 (error) 
strcmp( s1.c_str(), s2.c_str() ) // 2 (ok)

It would certainly be nice to do #1, but #1 is an error because strcmp requires two pointers and there's no automatic conversion from string to const char*. Number 2 is okay, but it's longer to write because we have to call c_str() explicitly.

So this Item's question really boils down to: Wouldn't it be better if we could just write #1?

Solution

graphics/bulb_icon.gif

The question was: The standard C++ string has no implicit conversion to a const char*. Should it?

The answer is: No, with good reason.

It's almost always a good idea to avoid writing automatic conversions, either as conversion operators or as single-argument non-explicit constructors.[2] The main reasons that implicit conversions are unsafe in general are:

[2] This solution focuses on the usual problems of implicit conversions, but there are other reasons why a string class should not have a conversion to const char*. Here are a few citations to further discussions: Koenig A. and Moo B. Ruminations on C++ (Addison Wesley Longman, 1997), pages 290?92. Stroustrup, Bjarne. The Design and Evolution of C++ (Addison-Wesley, 1994), page 83.

  • Implicit conversions can interfere with overload resolution.

  • Implicit conversions can silently let "wrong" code compile cleanly.

If a string had an automatic conversion to const char*, that conversion could be implicitly called anywhere the compiler felt it was necessary. What this means is that you would get all sorts of subtle conversion problems梩he same ones you get into when you have non-explicit conversion constructors. It becomes far too easy to write code that looks right, is in fact not right and should fail, but by sheer coincidence will compile by doing something completely different from what was intended.

There are many good examples. Here's a simple one:

string s1, s2, s3; 
s1 = s2 - s3;   // oops, probably meant "+"

The subtraction is meaningless and should be wrong. If string had an implicit conversion to const char*, however, this code would compile cleanly because the compiler would silently convert both strings to const char*'s and then subtract those pointers.

Guideline

graphics/guideline_icon.gif

Avoid writing conversion operators. Avoid non-explicit constructors.

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值