为什么operator ++返回非const值？ [英] Why does operator ++ return a non-const value?

问题描述

我已阅读Scott Meyers编写的Effective C ++ 3rd Edition。

本书的第3项，使用 const 只要可能，说如果我们想防止右值被意外分配给函数的返回值，返回类型应该是 const 。

例如， iterator 的增量函数：

  const iterator iterator :: operator ++（int）{
 ... 
} 
  

$ b b

然后，防止了一些事故。

  
 
 //与原始指针相同的错误
 //我想比较迭代器
 if（it ++ = iterator（））{
 ...然而，迭代器如 std :: vector：
} 
  


$ b < ：iterator 在GCC中不返回 const 值。

 code> vector< int> v; 
 v.begin（）++ = v.begin（）; // pass compiler check 
  

这有什么原因吗？

<我很确定这是因为它将使用右值引用和任何类型的 decltype 播放havoc 。即使这些功能不在C ++ 03中，它们也被称为即将到来。

更重要的是，我不相信任何标准函数返回const rvalues ，这可能是在标准发布后才考虑的。此外，常数一般不被认为是正确的事情。

例如，

  auto it = ++ vec.begin（）; 
  

是完全有效的，实际上是有效语义。考虑我提供方法链的类。

  class ILikeMethodChains {
 public：
 int i; 
 ILikeMethodChains& SetSomeInt（int param）{
 i = param; 
 return * this; 
} 
}; 
 ILikeMethodChains func（）{...} 
 ILikeMethodChains var = func（）。SetSomeInt（1）; 
  

如果不允许，只是因为，有时候，我们可能会调用一个没有意义的函数？不，当然不。或者如何swaptimization？

  std :: string func（）{returnHello World！ } 
 std :: string s; 
 func（）。swap（s）; 
  

如果 func（）产生一个const表达式 - 但它是完全有效的，并且确实，假设 std :: string 的实现不分配任何内存在默认构造函数，快速和易读/可读。

你应该意识到的是，C ++ 03的值/左值规则坦率地说没有意义。它们实际上只是部分烘焙的，并且是允许某些可能的权利不允许某些明显错误所需的最低限度。 C ++ 0x右值规则非常清楚，更完整。

I have read Effective C++ 3rd Edition written by Scott Meyers.

Item 3 of the book, "Use const whenever possible", says if we want to prevent rvalues from being assigned to function's return value accidentally, the return type should be const.

For example, the increment function for iterator:

const iterator iterator::operator++(int) {
    ...
}

Then, some accidents is prevented.

iterator it; 

// error in the following, same as primitive pointer
// I wanted to compare iterators
if (it++ = iterator()) {
  ...
}

However, iterators such as std::vector::iterator in GCC don't return const values.

vector<int> v;
v.begin()++ = v.begin();   // pass compiler check

Are there some reasons for this?

解决方案

I'm pretty sure that this is because it would play havoc with rvalue references and any sort of decltype. Even though these features were not in C++03, they have been known to be coming.

More importantly, I don't believe that any Standard function returns const rvalues, it's probably something that wasn't considered until after the Standard was published. In addition, const rvalues are generally not considered to be the Right Thing To Do™. Not all uses of non-const member functions are invalid, and returning const rvalues is blanketly preventing them.

For example,

auto it = ++vec.begin();

is perfectly valid, and indeed, valid semantics, if not exactly desirable. Consider my class that offers method chains.

class ILikeMethodChains {
public:
    int i;
    ILikeMethodChains& SetSomeInt(int param) {
        i = param;
        return *this;
    }
};
ILikeMethodChains func() { ... }
ILikeMethodChains var = func().SetSomeInt(1);

Should that be disallowed just because maybe, sometimes, we might call a function that doesn't make sense? No, of course not. Or how about "swaptimization"?

std::string func() { return "Hello World!"; }
std::string s;
func().swap(s);

This would be illegal if func() produced a const expression - but it's perfectly valid and indeed, assuming that std::string's implementation does not allocate any memory in the default constructor, both fast and legible/readable.

What you should realize is that the C++03 rvalue/lvalue rules frankly just don't make sense. They are, effectively, only part-baked, and the minimum required to disallow some blatant wrongs whilst allowing some possible rights. The C++0x rvalue rules are much saner and much more complete.

这篇关于为什么operator ++返回非const值？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！