C++重载[]运算符时const成员函数为何不能返回非const引用

示例代码 #

#include <iostream>
using namespace std;

struct valStruct {
    double& operator[](int i){return values[i];};       // 第6行
    double operator[](int i) const {return values[i];}; // 第7行
    double values[4];
};

int main () {
    valStruct vals = {0,1,2,3};
    cout << "Value before change" << endl;
    for ( int i = 0; i < 3; i++ ) {
        cout << "vals[" << i << "] = "<< vals[i] << endl;
    }

    vals[1] = 2.2; // 修改第二个元素
 
    cout << "Value after change" << endl;
    for ( int i = 0; i < 3; i++ ) {
        cout << "vals[" << i << "] = "<< vals.values[i] << endl;
    }
    return 0;
}

核心疑问 #

• 第6行的非const版本operator[]已经支持读写操作，为什么还需要实现第7行的const重载版本？
• 为什么const版本的operator[]不能写成double& operator[](int i) const {return values[i];}的形式，否则会抛出binding reference of type ‘double&’ to ‘const double’ discards qualifiers的编译错误？

原理解答 #

C++成员函数的重载匹配会根据调用对象的const属性自动选择对应版本，不存在“非const版本存在就覆盖const版本”的情况：

• 调用方是非const类实例时，优先匹配第6行的非constoperator[]。这个版本返回double&类型的可修改引用，既支持读取元素值，也支持直接给元素赋值写入，示例中vals[1] = 2.2的修改操作就是走的这个版本。
• 调用方是const修饰的类实例、const引用、const指针时，编译器禁止它调用非const成员函数——非const成员函数的语义是“可能修改对象状态”，这和const实例的只读属性冲突，这种场景下就必须调用const版本的operator[]，这就是第7行存在的核心价值：给const场景的实例提供下标访问能力。

关于编译错误的原因，本质是const成员函数的隐含规则：const成员函数内部的this指针是指向const对象的，也就是说在const成员函数的作用域里，类的所有非静态成员都会被视为const类型。
在第7行的constoperator[]中，数组成员values的类型相当于const double[4]，取下标拿到的单个元素是const double类型。如果声明返回值是double&（非const引用），相当于给只读的const值绑定了一个可修改的引用，直接绕过了const的只读保护，编译器会直接拦截这个非法操作，抛出你看到的“discards qualifiers”（丢弃类型限定符）错误。

你示例中第7行返回的是double值类型，这种写法是合法的——因为是把元素值拷贝一份返回，不会修改原成员的只读属性，只是会多一次拷贝开销。实际工程里更推荐把const版本写成const double& operator[](int i) const {return values[i];}，既没有拷贝开销，又能保证返回的引用不能用来修改原成员，完全符合const语义。

举一个必须依赖const重载的常见场景：

// 函数参数传const引用，避免拷贝同时承诺不修改入参
void printVals(const valStruct& v) {
    for (int i = 0; i < 4; i++) {
        cout << v[i] << endl; // 这里v是const引用，只能调用const版本的operator[]
    }
}

如果只实现非const版本的operator[]，上面这种传const引用的常规写法会直接编译失败，这就是为什么哪怕非const版本已经支持读写，也必须额外实现const重载的原因。

内容的提问来源于stack exchange，提问作者user304584