不要返回局部对象的引用,也不要返回函数内部用new初始化的指针的引用

本文探讨了在C++中返回局部对象引用的问题,解释了为何这样做会导致未定义行为,并讨论了使用new来规避此问题时可能引发的内存泄漏。此外,还提出了避免这些问题的最佳实践。

听起来很复杂,其实不然。它只是一个很简单的道理,真的,相信我。

先看第一种情况:返回一个局部对象的引用。它的问题在于,局部对象 ----- 顾名思义 ---- 仅仅是局部的。也就是说,局部对象是在被定义时创建,在离开生命空间时被销毁的。所谓生命空间,是指它们所在的函数体。当函数返回时,程序的控制离开了这个空间,所以函数内部所有的局部对象被自动销毁。因此,如果返回局部对象的引用,那个局部对象其实已经在函数调用者使用它之前被销毁了。

当想提高程序的效率而使函数的结果通过引用而不是值返回时,这个问题就会出现。下面的例子和条款23中的一样,其目的在于详细说明什么时候该返回引用,什么时候不该:

class rational {          // 一个有理数类
public:
rational(int numerator = 0, int denominator = 1);
~rational();

...

private:
int n, d;               // 分子和分母

// 注意operator* (不正确地)返回了一个引用
friend const rational& operator*(const rational& lhs,
                                 const rational& rhs);
};

// operator*不正确的实现
inline const rational& operator*(const rational& lhs,
                                 const rational& rhs)
{
rational result(lhs.n * rhs.n, lhs.d * rhs.d);
return result;
}

这里,局部对象result在刚进入operator*函数体时就被创建。但是,所有的局部对象在离开它们所在的空间时都要被自动销毁。具体到这个例子来说,result是在执行return语句后离开它所在的空间的。所以,如果这样写:

rational two = 2;

rational four = two * two;         // 同operator*(two, two)


函数调用时将发生如下事件:

1. 局部对象result被创建。
2. 初始化一个引用,使之成为result的另一个名字;这个引用先放在另一边,留做operator*的返回值。
3. 局部对象result被销毁,它在堆栈所占的空间可被本程序其它部分或其他程序使用。
4. 用步骤2中的引用初始化对象four。

一切都很正常,直到第4步才产生了错误,借用高科技界的话来说,产生了"一个巨大的错误"。因为,第2步被初始化的引用在第3步结束时指向的不再是一个有效的对象,所以对象four的初始化结果完全是不可确定的。

教训很明显:别返回一个局部对象的引用。

"那好,"你可能会说,"问题不就在于要使用的对象离开它所在的空间太早吗?我能解决。不要使用局部对象,可以用new来解决这个问题。"象下面这样:

// operator*的另一个不正确的实现
inline const rational& operator*(const rational& lhs,
                                 const rational& rhs)
{
// create a new object on the heap
rational *result =
    new rational(lhs.n * rhs.n, lhs.d * rhs.d);

// return it
return *result;
}

这个方法的确避免了上面例子中的问题,但却引发了新的难题。大家都知道,为了在程序中避免内存泄漏,就必须确保对每个用new产生的指针调用delete,但是,这里的问题是,对于这个函数中使用的new,谁来进行对应的delete调用呢?

显然,operator*的调用者应该负责调用delete。真的显然吗?遗憾的是,即使你白纸黑字将它写成规定,也无法解决问题。之所以做出这么悲观的判断,是基于两条理由:

第一,大家都知道,程序员这类人是很马虎的。这不是指你马虎或我马虎,而是指,没有哪个程序员不和某个有这类习性的人打交道。想让这样的程序员记住无论何时调用operator*后必须得到结果的指针然后调用delete,这样的几率有多大呢?也是说,他们必须这样使用operator*:

const rational& four = two * two;      // 得到废弃的指针;
                                       // 将它存在一个引用中
...

delete &four;                          // 得到指针并删除

这样的几率将会小得不能再小。记住,只要有哪怕一个operator*的调用者忘了这条规则,就会造成内存泄漏。

返回废弃的指针还有另外一个更严重的问题,即使是最尽责的程序员也难以避免。因为常常有这种情况,operator*的结果只是临时用于中间值,它的存在只是为了计算一个更大的表达式。例如:

rational one(1), two(2), three(3), four(4);
rational product;

product = one * two * three * four;

product的计算表达式需要三个单独的operator*调用,以相应的函数形式重写这个表达式会看得更清楚:

product = operator*(operator*(operator*(one, two), three), four);

是的,每个operator*调用所返回的对象都要被删除,但在这里无法调用delete,因为没有哪个返回对象被保存下来。

解决这一难题的唯一方案是叫用户这样写代码:

const rational& temp1 = one * two;
const rational& temp2 = temp1 * three;
const rational& temp3 = temp2 * four;

delete &temp1;
delete &temp2;
delete &temp3;

果真如此的话,你所能期待的最好结果是人们将不再理睬你。更现实一点,你将会在指责声中度日,或者可能会被判处10年苦力去写威化饼干机或烤面包机的微代码。

所以要记住你的教训:写一个返回废弃指针的函数无异于坐等内存泄漏的来临。

另外,假如你认为自己想出了什么办法可以避免"返回局部对象的引用"所带来的不确定行为,以及"返回堆(heap)上分配的对象的引用"所带来的内存泄漏,那么,请转到条款23,看看为什么返回局部静态(static)对象的引用也会工作不正常。看了之后,也许会帮助你避免头痛医脚所带来的麻烦。

<think>好的,用户的问题是关于在C++中返回函数局部变量时,使用引用还是指针的优劣及适用场景。我需要结合用户提供的引用资料和之前的回答来给出全面的解答。 首先,用户提供的引用内容中有几个关键点需要注意。引用[1]提到返回局部变量的引用类似于野指针,会导致未定义行为。引用[2]讨论了返回局部对象时的编译器优化(RVO)。引用[3]指出返回局部变量的值是可以的,但返回地址会导致问题,除非指向堆内存。引用[4]展示了一种通过静态局部变量延长生命周期的方法。引用[5]提到传递指针时的内存管理问题。 用户之前的问题涉及返回局部变量内存地址的危险以及安全方法,如使用静态变量、堆内存或参数传递。现在用户想比较返回局部变量时引用指针的优劣,以及适用场景。 我需要整理以下几点: 1. **返回引用的风险**:如果返回局部变量的引用函数结束后栈内存被释放,引用变成悬垂引用,类似野指针,导致未定义行为。例如引用[1]中的例子。 2. **返回指针的风险**:返回局部变量的指针同样会导致悬垂指针,访问已释放的内存。但如果是堆内存或静态变量则安全,如引用[3]和[4]所述。 3. **安全返回的方法**: - 静态局部变量:延长生命周期至程序结束,如引用[4]中的示例。 - 堆内存分配:需手动管理内存,可能引起泄漏。 - 参数传递:由调用方管理内存,避免所有权问题。 4. **编译器优化(RVO)**:引用[2]提到编译器优化可以避免拷贝,直接构造返回值,提高效率。但需注意,这适用于返回值而非指针引用。 5. **引用指针的比较**: - 语法差异:引用不能为null,必须初始化,更安全;指针更灵活,可重新指向。 - 生命周期管理:返回堆内存时,指针需显式释放,而引用可能隐藏资源管理细节。 - 适用场景:静态变量或全局变量可返回引用;动态分配推荐使用智能指针。 6. **最佳实践**: - 避免返回局部对象引用指针,除非使用静态或堆内存。 - 优先返回值,利用编译器优化。 - 使用智能指针管理所有权,避免泄漏。 - 参数传递法明确内存管理责任。 需要结合用户之前的回答,强调生命周期管理和所有权的重要性,并比较引用指针在不同场景下的适用性。同时,需要指出何时使用哪种方法更安全,比如静态变量适合单线程,而多线程需考虑同步问题。智能指针在C++11之后是更好的选择,避免手动管理内存。 可能还需要提到返回引用指针的性能考虑,比如返回对象引用指针更高效,但必须确保有效性。此外,错误示例和正确做法的对比能帮助用户更好理解。 最后,总结最佳实践,并回答用户的问题:返回局部变量时,引用指针都有风险,除非使用静态或堆内存。推荐返回值或使用智能指针,参数传递法也是安全的选择。适用场景包括需要避免拷贝的大对象,或者需要多态返回类型时使用静态派生类对象。</think>以下是关于C++中函数返回局部变量时使用引用指针的对比分析及最佳实践指南: --- ### 一、核心问题分析 #### 1. **返回局部变量本身的危险性** - **栈内存特性**:函数内部局部变量(非静态)存储在栈中,函数返回后栈帧销毁,原内存失效[^1][^3] - **悬垂引用/指针**:返回局部变量的引用指针,将导致指向无效内存的访问(未定义行为)[^1][^3] #### 2. **引用指针的本质差异** | 特性 | 引用 | 指针 | |---------------------|----------------------------------------------------------------------|----------------------------------------------------------------------| | 空值合法性 | 必须绑定有效对象,不可为`null` | 可以为`nullptr` | | 内存管理 | 语法上不涉及显式内存操作 | 需关注所有权和释放 | | 可重定向性 | 一旦初始化不可更改绑定对象 | 可修改指向地址 | | 语法安全性 | 编译期更严格的类型检查 | 需手动处理地址运算 | --- ### 二、安全返回策略对比 #### 1. **静态局部变量(适用引用/指针)** ```cpp // 安全返回静态局部变量的引用 const MyClass& getInstance() { static MyClass instance; // 静态存储期,生命周期至程序结束[^4] return instance; } // 返回静态指针 MyClass* getStaticPtr() { static MyClass obj; return &obj; // 合法但通常不如引用直观[^4] } ``` *适用场景*:单例模式、全局配置对象 #### 2. **堆内存分配(仅适用指针)** ```cpp // 返回堆内存指针(需调用者释放) int* createHeapInt() { return new int(42); // 所有权转移给调用者[^5] } // C++11后更推荐智能指针 std::unique_ptr<MyClass> createObj() { return std::make_unique<MyClass>(); } ``` *注意事项*:必须明确所有权归属,避免内存泄漏[^5] #### 3. **参数传递法(适用引用/指针)** ```cpp // 通过引用参数填充数据 void fillData(std::vector<int>& output) { output.push_back(100); // 操作外部对象[^5] } // 通过指针参数返回结果 void calculate(int* result) { *result = 200; // 需确保指针有效 } ``` *优势*:内存管理责任明确,无生命周期风险 --- ### 三、引用指针的选择策略 #### 1. **优先使用引用的情况** - 返回**静态/全局对象**时(确保生命周期) - 需要**链式调用**(如运算符重载) - 接口设计强调**不可为空**的返回值 ```cpp // 示例:工厂方法返回静态对象引用 Logger& Logger::get() { static Logger instance; return instance; } ``` #### 2. **必须使用指针的情况** - 需要返回**动态分配的对象** - 需要支持**多态返回类型** - 允许返回空值表示特殊状态 ```cpp // 示例:多态工厂 Base* createObject(int type) { if(type == 1) return new DerivedA(); else return nullptr; // 指针支持空值 } ``` #### 3. **禁止直接返回的情况** ```cpp // 危险:返回局部引用(编译警告但可通过编译) int& badRefReturn() { int x = 10; return x; // 悬垂引用![^1] } // 危险:返回局部指针 int* badPtrReturn() { int y = 20; return &y; // 悬垂指针![^3] } ``` --- ### 四、现代C++最佳实践 1. **优先返回值而非引用/指针** ```cpp // 利用返回值优化(RVO/NRVO) std::vector<int> generateData() { std::vector<int> data {1,2,3}; return data; // 编译器优化避免拷贝[^2] } ``` 2. **智能指针管理所有权** ```cpp // 明确所有权转移 std::shared_ptr<Resource> loadResource() { return std::make_shared<Resource>(); } ``` 3. **静态局部变量的线程安全** ```cpp // C++11后静态局部变量初始化线程安全 MyClass& getThreadSafeInstance() { static MyClass instance; // 线程安全初始化 return instance; } ``` 4. **返回视图而非所有权** ```cpp // 返回const引用避免修改 const std::string& getName() const { return cachedName; // 假设cachedName为成员变量 } ``` --- ### 五、决策流程图 ```mermaid graph TD A[需要返回局部数据?] -->|是| B{数据生命周期需求} B -->|需延长生命周期| C[静态局部变量+引用] B -->|需动态管理| D[堆内存+智能指针] A -->|否| E[优先返回值+RVO优化] C --> F[单例/全局配置场景] D --> G[多态对象/资源管理场景] E --> H[常规数据传递] ``` --- ### 六、关键结论 1. **引用更适合**:返回**长期有效**的对象,强调非空、不可重绑定特性 2. **指针更灵活**:需处理空状态、多态或动态内存时使用,但需配合智能指针 3. **根本原则**:确保返回引用/指针**指向的内存有效时间 ≥ 其使用时间** 4. **现代实践**:优先使用**返回值优化**和**智能指针**,减少裸指针/引用操作
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值