请考虑以下代码:
#include <iostream>
struct B {
void bar() {
std::cout << "I feel used\n";
}
};
struct A {
B& b;
A(B& b_) : b(b_) {} // take and keep a reference to the object passed in
void foo() {
b.bar(); // potentially change the state of b
}
};
int main() {
B b;
A a(b);
a.foo();
}
A
的构造函数将b
作为参数引用,A
通过引用更改其成员函数中b
的状态。
我的问题:
答案 0 :(得分:3)
这样做是否是一种好习惯?
它可以非常危险。你需要确保B将比参考B的A更长。有时候,使用OP中所示的引用是非常明智的。
有什么缺点?
确保B在某些情况下比A更长,这可能非常棘手,如果您引用参数而不是复制它,它可能会让客户感到惊讶。
什么可以替代?
std::shared_ptr
如果是外部拥有的。否则,复制或合成会降低复杂性。
class C { // OK - b obviously outlives a
C() : b(), a(b) {}
B b;
A a;
};
答案 1 :(得分:1)
在一个简单的程序中,你所做的很好。
我认为你会发现在任何复杂程序(IE不是简单的语言样本)的程序中,你最终需要一个指针(或者更好的是shared_ptr),而不是保留一个引用的生命周期对象。
如果你可以在整个时间内保留一个你可能应该使用你完全拥有的对象的引用,那么很有可能。为什么?当该引用超出范围并被销毁时,您打算做什么?
答案 2 :(得分:1)
您在此处描述的内容与设计的关系更紧密,而不是C++
(或其他语言)的技术方面,在dependency
中称为UML
。这是一种常见做法,对于任何其他技术都应该在使用前应用适当的分析 - 以了解它是否真的适合您的问题的解决方案。您可以找到更多详细信息和用法示例here。