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

SOHERE查看

于 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 回答