| 查看: 1705 | 回复: 6 | ||
| 当前只显示满足指定条件的回帖，点击这里查看本话题的所有回帖 | ||
[求助]
VC++中函数返回数组指针或者带指针的结构体的编译方式是否可取？
|
||
|
偶以前经常采用这种方式来进行C++的编程，只是在用delete释放内存时需要小心一些。 用这种方式编程的一个好处在于，比如计算矩阵运算，例如A+B时，可采用运算符+的重载来进行，这样在使用程序包时会很方便。 可最近喜欢在结构体中的使用析构函数，发现有个问题，就是子函数返回结构体时，会自动执行析构函数（即使当此结构体为外部变量时依然如此），因此把结构体中的指针内存提早释放，导致返回的结构体中的指针也相应被释放，最终出错。 我看书中的程序范例在计算矩阵或者多项式时，都不是采用运算符重载，而是用常规的函数，把所用用到的结构体都用加&的方式赋过来，才不会被析构函数释放，可这种操作显然太麻烦？但不知道是不是以前我的编程方式，本身就是一种错误的习惯，还是说干脆放弃使用析构函数，每次手动释放内存？可是有没有更好的方式可以二者兼得呢？ |
回复此楼» 猜你喜欢
2025冷门绝学什么时候出结果
已经有3人回复
-
天津工业大学郑柳春团队欢迎化学化工、高分子化学或有机合成方向的博士生和硕士生加入
已经有4人回复
-
康复大学泰山学者周祺惠团队招收博士研究生
已经有6人回复
-
AI论文写作工具：是科研加速器还是学术作弊器？
已经有3人回复
-
孩子确诊有中度注意力缺陷
已经有6人回复
-
2026博士申请-功能高分子，水凝胶方向
已经有6人回复
-
论文投稿，期刊推荐
已经有4人回复
-
硕士和导师闹得不愉快
已经有13人回复
-
请问2026国家基金面上项目会启动申2停1吗
已经有5人回复
-
同一篇文章，用不同账号投稿对编辑决定是否送审有没有影响？
已经有3人回复
» 本主题相关价值贴推荐，对您同样有帮助:
[求助]河南或者西安有那个学校的乳品专业研究生比较好？
已经有10人回复- 帮忙给看看这个matlab优化函数 问题
已经有8人回复
- 【转载】世界数学名题欣赏丛书-无处可微的连续函数【已搜无重复】
已经有83人回复
- 使用PGI编译VASP中无法使用长数组
已经有5人回复
- 结构体所占内存
已经有8人回复
- 三维数组换行输入到文件（intel fortran 编译器）
已经有6人回复
- 【求助】使用按照版主编译出来的music_gcmc.exe运行自带的第8个例子的问题
已经有10人回复
- 【求助】从文件读入数组遇到困难
已经有3人回复
- 【求助】fluent计算中，udf编译通过，初始化出错
已经有11人回复
- 【求助】VASP考虑自旋轨道耦合的话，如何编译
已经有17人回复
nebulaly
木虫 (著名写手)
- 应助: 7 (幼儿园)
- 金币: 4170.1
- 散金: 220
- 红花: 5
- 帖子: 1311
- 在线: 410.5小时
- 虫号: 910959
- 注册: 2009-11-24
- 专业: 计算机应用技术
3楼2012-07-08 01:54:06
libralibra
至尊木虫 (著名写手)
骠骑将军
- 程序强帖: 40
- 应助: 817 (博后)
- 金币: 12914.1
- 红花: 64
- 帖子: 2238
- 在线: 287.3小时
- 虫号: 696514
- 注册: 2009-02-05
- 专业: 计算机软件
2楼2012-07-07 18:58:14
|
matrix operator+(matrix& A) //矩阵加法 { int i,j; ANSm.build(m,n); if(n!=A.n||m!=A.m) { printf("\nERROR!!!\n行列不对应的两个矩阵不能相加。"  ;return ANSm; } for(i=0;i return ANSm; } 这是定义在结构体matrix中的一个成员，用于计算矩阵加法，其中m,n分别表示矩阵的行与列，二重指针M对应矩阵的二维数组，对象ANSm是在外部定义的，在返回ANSm后，它就自动执行了ANSm中的析构函数，因此把返回结构体中的指针也释放了。 目前偶的一个办法就是在结构体中增加一个判定变量，使得析构函数在主函数main结束前，不能释放ANSm中的指针。 |
4楼2012-07-08 09:39:47
nebulaly
木虫 (著名写手)
- 应助: 7 (幼儿园)
- 金币: 4170.1
- 散金: 220
- 红花: 5
- 帖子: 1311
- 在线: 410.5小时
- 虫号: 910959
- 注册: 2009-11-24
- 专业: 计算机应用技术
|
条款23: 必须返回一个对象时不要试图返回一个引用 据说爱因斯坦曾提出过这样的建议：尽可能地让事情简单，但不要过于简 单。在C++语言中相似的说法应该是：尽可能地使程序高效，但不要过于高效。 一旦程序员抓住了“传值”在效率上的把柄（参见条款22），他们会变得 十分极端，恨不得挖出每一个隐藏在程序中的传值操作。岂不知，在他们不懈 地追求纯粹的“传引用”的过程中，他们会不可避免地犯另一个严重的错误： 传递一个并不存在的对象的引用。这就不是好事了。 看一个表示有理数的类，其中包含一个友元函数，用于两个有理数相乘： class Rational { public: Rational(int numerator = 0, int denominator = 1); ... private: int n, d; // 分子和分母 friend const Rational // 参见条款21：为什么 operator*(const Rational& lhs, // 返回值是const const Rational& rhs) }; inline const Rational operator*(const Rational& lhs, const Rational& rhs) { return Rational(lhs.n * rhs.n, lhs.d * rhs.d); } 很明显，这个版本的operator*是通过传值返回对象结果，如果不去考虑对 象构造和析构时的开销，你就是在逃避作为一个程序员的责任。另外一件很明 显的事实是，除非确实有必要，否则谁都不愿意承担这样一个临时对象的开销。 那么，问题就归结于：确实有必要吗？ 答案是，如果能返回一个引用，当然就没有必要。但请记住，引用只是一 个名字，一个其它某个已经存在的对象的名字。无论何时看到一个引用的声明， 就要立即问自己：它的另一个名字是什么呢？因为它必然还有另外一个什么名 字（见条款M1）。拿operator*来说，如果函数要返回一个引用，那它返回的必 须是其它某个已经存在的Rational 对象的引用，这个对象包含了两个对象相乘 的结果。 但，期望在调用 operator*之前有这样一个对象存在是没道理的。也就是说， 如果有下面的代码： Rational a(1, 2); // a = 1/2 Rational b(3, 5); // b = 3/5 Rational c = a * b; // c 为 3/10 期望已经存在一个值为 3/10 的有理数是不现实的。如果operator* 一定要 返回这样一个数的引用，就必须自己创建这个数的对象。 一个函数只能有两种方法创建一个新对象：在堆栈里或在堆上。在堆栈里 创建对象时伴随着一个局部变量的定义，采用这种方法，就要这样写operator*： // 写此函数的第一个错误方法 inline const Rational& operator*(const Rational& lhs, const Rational& rhs) { Rational result(lhs.n * rhs.n, lhs.d * rhs.d); return result; } 这个方法应该被否决，因为我们的目标是避免构造函数被调用，但 result 必须要象其它对象一样被构造。另外，这个函数还有另外一个更严重的问题， 它返回的是一个局部对象的引用，关于这个错误，条款31 进行了深入的讨论。 那么，在堆上创建一个对象然后返回它的引用呢？基于堆的对象是通过使 用new 产生的，所以应该这样写operator*： // 写此函数的第二个错误方法 inline const Rational& operator*(const Rational& lhs, const Rational& rhs) { Rational *result = new Rational(lhs.n * rhs.n, lhs.d * rhs.d); return *result; } 首先，你还是得负担构造函数调用的开销，因为 new 分配的内存是通过调 用一个适当的构造函数来初始化的（见条款5 和M8）。另外，还有一个问题： 谁将负责用delete 来删除掉new 生成的对象呢？ 实际上，这绝对是一个内存泄漏。即使可以说服 operator*的调用者去取函 数返回值地址，然后用delete 去删除它（绝对不可能——条款31 展示了这样 的代码会是什么样的），但一些复杂的表达式会产生没有名字的临时值，程序员 是不可能得到的。例如： Rational w, x, y, z; w = x * y * z; 两个对 operator*的调用都产生了没有名字的临时值，程序员无法看到，因 而无法删除。（再次参见条款31） 也许，你会想你比一般的熊——或一般的程序员——要聪明；也许，你注 意到在堆栈和堆上创建对象的方法避免不了对构造函数的调用；也许，你想起 了我们最初的目标是为了避免这种对构造函数的调用；也许，你有个办法可以 只用一个构造函数来搞掂一切；也许，你的眼前出现了这样一段代码：operator* 返回一个“在函数内部定义的静态Rational 对象”的引用： // 写此函数的第三个错误方法 inline const Rational& operator*(const Rational& lhs, const Rational& rhs) { static Rational result; // 将要作为引用返回的 // 静态对象 lhs 和rhs 相乘，结果放进result； return result; } 这个方法看起来好象有戏，虽然在实际实现上面的伪代码时你会发现，不 调用一个Rational 构造函数是不可能给出result 的正确值的，而避免这样的调 用正是我们要谈论的主题。就算你实现了上面的伪代码，但，你再聪明也不能 最终挽救这个不幸的设计。 想知道为什么，看看下面这段写得很合理的用户代码： bool operator==(const Rational& lhs, // Rationals 的operator== const Rational& rhs); // Rational a, b, c, d; ... if ((a * b) == (c * d)) { 处理相等的情况; } else { 处理不相等的情况; } 看出来了吗？((a*b) == (c*d)) 会永远为true，不管a，b，c 和d 是什么值！ 用等价的函数形式重写上面的相等判断语句就很容易明白发生这一可恶行 为的原因了： if (operator==(operator*(a, b), operator*(c, d))) 注意当 operator==被调用时，总有两个operator*刚被调用，每个调用返回 operator*内部的静态Rational 对象的引用。于是，上面的语句实际上是请求 operator==对“operator*内部的静态Rational 对象的值”和“operator*内部的 静态Rational 对象的值”进行比较，这样的比较不相等才怪呢！ 幸运的话，我以上的说明应该足以说服你：想“在象operator*这样的函数 里返回一个引用”实际上是在浪费时间。但我没幼稚到会相信幸运总会光临自 己。一些人——你们知道这些人是指谁——此刻会在想，“唔，上面那个方法， 如果一个静态变量不够用，也许可以用一个静态数组⋯⋯” 请就此打住！我们难道还没受够吗？ 我不能让自己写一段示例代码来太高这个设计，因为即使只抱有上面这种 想法都足以令人感到羞愧。首先，你必须选择一个n，指定数组的大小。如果 n 太小，就会没地方储存函数返回值，这和我们前面否定的那个“采用单个静 态变量的设计”相比没有什么改进。如果n 太大，就会降低程序的性能，因为 函数第一次被调用时数组中每个对象都要被创建。这会带来n 个构造函数和n 个析构函数的开销，即使这个函数只被调用一次。如果说"optimization"（最优 化） 是指提高软件的性能的过程， 那 么 现 在 这 种 做 法 简 直 可 以 称 为 "pessimization"（最差化）。最后，想想怎么把需要的值放到数组的对象中以及 需要多大的开销？在对象间传值的最直接的方法是通过赋值，但赋值的开销又 有多大呢？一般来说，它相当于调用一个析构函数（摧毁旧值）再加上调用一 个构造函数（拷贝新值）。但我们现在的目标正是为了避免构造和析构的开销啊！ 面对现实吧：这个方法也绝对不能选用。 所以，写一个必须返回一个新对象的函数的正确方法就是让这个函数返回 一个新对象。对于Rational 的operator*来说，这意味着要不就是下面的代码（就 是最初看到的那段代码），要不就是本质上和它等价的代码： inline const Rational operator*(const Rational& lhs, const Rational& rhs) { return Rational(lhs.n * rhs.n, lhs.d * rhs.d); } 的确，这会导致“operator*的返回值构造和析构时带来的开销”，但归根 结底它只是用小的代价换来正确的程序运行行为而已。况且，你所担心的开销 还有可能永远不会出现：和所有程序设计语言一样，C++允许编译器的设计者 采用一些优化措施来提高所生成的代码的性能，所以，在有些场合，operator* 的返回值会被安全地除去（见条款M20）。当编译器采用了这种优化时（当前 大部分编译器这么做），程序和以前一样继续工作，只不过是运行速度比你预计 的要快而已。 以上讨论可以归结为：当需要在返回引用和返回对象间做决定时，你的职 责是选择可以完成正确功能的那个。至于怎么让这个选择所产生的代价尽可能 的小，那是编译器的生产商去想的事。 |
5楼2012-07-10 23:41:18