1

可能重复：
常量正确性是否为编译器提供了更多优化空间？

在过去的几个星期里，我开发了一个东西，const如果可能的话，让我的所有非静态成员都成为非静态成员，以避免意外的编程错误。然而，这种做法提供了一些巨大的缺点，特别是对于实体对象，因为例如，如果他们选择直接聚合这样的实体对象而不是使用指针，那么没有人将能够再调用赋值运算符。

我的问题是，这种const成员哲学是否甚至提供任何编译器优化奖励。

class User {
public:
    User(const std::string &, const std::vector<unsigned char> &);
    ~User();
    const std::string &getName() const;
    const std::vector<unsigned char> &getPasswordHash() const;
private:
    std::string name;
    std::vector<unsigned char> passwordHash;
};

如果 this class' 成员是，它会为我的编译器提供任何重要的优化可能性const吗？鉴于其他类通常会聚合非常量User对象，但几乎我所有的算法都会接受const User &?

那么，成员们是否对现有的心态const提供了任何重大的优化机会？const User &它会证明使用const User *聚合并在更改时重建对象而不是使用赋值运算符是合理的吗？

感谢您的快速评论！

4

2 回答 2

2

在SO和HERE查看

于 2012-03-07T09:43:56.250 回答
1

首先，关于词汇表的注释：根据定义，实体对象具有标识，因此不支持赋值。我认为你的意思是价值对象。

否则：我通常发现将数据成员设为 const 几乎没有什么优势。正如您所注意到的，这样做会使赋值变得不可能，这意味着它们对于值类型不能是 const 。对于无法分配的实体对象，将不可变成员（例如标识符）设为 const 有一些价值，但由于所有访问都在您控制的一小段代码中，因此该值比它的值要小得多const在公共界面。

另一种可能性是为此类成员定义不可变类型。name将其定义为 anIdentifier比将其定义为std::string, and更具表现力Identifier，即使它仅包含一个具有类型的数据成员std::string也会限制您可以使用它执行的操作。（这也将有助于稍后更改标识符的表示。）

于 2012-03-07T09:49:43.287 回答