对象生命周期要求公约 [英] Convention for Object Lifetime Requirement
问题描述
假设A类依赖于B类，因为B类
的对象被传递给A'的构造函数。见下文：
B级{...};
A级{
公开：
A（B const& b）;
...
};
是否有人使用任何约定（注释，代码等）表示
是否A类的对象要求b存在于对A'的构造函数的
调用之外？
例如，在复制构造函数的情况下，我会发现奇怪的是
了解某些类O的对象o1和o2，其中o1是<从o2构造的
，o1要求o2存在于o1的
构造函数之外。
我想要将讨论扩展到其他类型的依赖项，例如
，当A声明一个成员函数，该函数将
B类的对象作为参数。
< br $>
谢谢：
Belebele
3月29日2006 11:23:30 -0800，Belebele <是****** @ gmail.com>写道：假设A类依赖于B类，因为B类的对象被传递到A'的构造函数中。见下文：
B班{...};
A班{
公开：
A（B const& b）;
...
};
是否有人使用任何约定（注释，代码等）来表明A类的对象是否需要b存在于其他之外
打电话给A'的构造函数？
否。此设置似乎是反成语。当A依赖于B然后
让A在构造函数中创建B：
A类{
B b;
public：
A（int i）：b（i）{}
...
};
例如，在复制构造函数的情况下，我会发现奇怪的是要知道某些类O的对象o1和o2，其中o1是从o2，o1构造的要求o2存在于o1'的构造函数调用之外。
在这种情况下，您只能阻止复制构造和分配。
我想将讨论扩展到其他类型的依赖项，
例如，当A声明一个成员函数，该函数将类B的对象作为参数。
对''outside''对象的引用也违反了封装。如果A
确实需要B，那么将B对象作为参数传递给函数，例如。
A级{
/ /如上所述
void foo（const B& b，float f）{...}
...
};
祝福，
Roland Pibinger
Belebele写道：假设A类依赖于B类，因为B类的对象被传递到A'的构造函数中。见下文：
B班{...};
A班{
公开：
A（B const& b）;
...
};
是否有人使用任何约定（注释，代码等）来表明A类的对象是否需要b存在于其他之外
打电话给A'的构造函数？
是的，当
存在某种特殊关系时，使用智能指针代替原始指针或引用。例如，如果A接管B对象的
所有权，则传递std :: auto_ptr< B>进入A'的构造函数，
或者如果A没有唯一拥有该B对象但需要它在构造函数完成之后存在，则接受一个std： ：TR1 :: shared_ptr的< B个（或
boost :: shared_ptr< B>）或类似的，并将其存储为A的成员。
例如，在复制构造函数的情况下，我会找到奇怪地了解到某些O类的对象o1和o2，其中o1是从o2构造的，o1要求o2存在于o1'的构造函数的调用之外。 />
我想将讨论扩展到其他类型的依赖项，例如，当A声明一个成员函数，它将类B的对象作为参数。
同样的习语适用于这两种情况，例如。
干杯！ --M
Roland Pibinger写道：
不。这个设置似乎是一个反成语。当A依赖于B然后
让A在构造函数中创建B：
A类{
B b;
公开：
A（int i ）：b（i）{}
...
};
Google forconstruction encapsulation。
（并且看到每年这个新闻组如何获得帖子
从过去的良好模因中贬低，就像它们是神话一样，这是令人感到温暖的，或者
" anti-idioms" ...}
-
Phlip
http://www.greencheese.org/ZeekLand < - 不是博客!!! />
Suppose that a class A depends on class B because an object of class B
is passed into A''s constructor. See below:
class B { ... };
class A {
public:
A(B const& b);
...
};
Does anybody use any convention (comment, code, etc) to indicate
whether or not the object of class A requires b to exist beyond the
call to A''s constructor?
For example, in the case of copy constructors, I would find odd to
learn that for objects o1 and o2 of certain class O, where o1 was
constructed from o2, o1 requires o2 to exist beyond the call to o1''s
constructor.
I would like to extend the discussion to other types of dependencies,
for example, when A declares a member function that takes an object of
class B as a parameter.
Thanks:
Belebele
On 29 Mar 2006 11:23:30 -0800, "Belebele" <be******@gmail.com> wrote:Suppose that a class A depends on class B because an object of class B
is passed into A''s constructor. See below:
class B { ... };
class A {
public:
A(B const& b);
...
};
Does anybody use any convention (comment, code, etc) to indicate
whether or not the object of class A requires b to exist beyond the
call to A''s constructor?
No. This setting seems to be an anti-idiom. When A depends on B then
let A create B in the constructor:
class A {
B b;
public:
A (int i) : b(i) {}
...
};
For example, in the case of copy constructors, I would find odd to
learn that for objects o1 and o2 of certain class O, where o1 was
constructed from o2, o1 requires o2 to exist beyond the call to o1''s
constructor.
In that case you can only prevent copy construction and assignment.
I would like to extend the discussion to other types of dependencies,
for example, when A declares a member function that takes an object of
class B as a parameter.
References to ''outside'' objects also violates encapsulation. If A
really needs B then pass a B object as argument to the function, eg.
class A {
// as above
void foo (const B& b, float f) { ... }
...
};
Best wishes,
Roland Pibinger
Belebele wrote:Suppose that a class A depends on class B because an object of class B
is passed into A''s constructor. See below:
class B { ... };
class A {
public:
A(B const& b);
...
};
Does anybody use any convention (comment, code, etc) to indicate
whether or not the object of class A requires b to exist beyond the
call to A''s constructor?
Yes, use smart pointers instead of raw pointers or references when
there is some special relationship. For instance, if A takes over
ownership of a B object, pass a std::auto_ptr<B> into A''s constructor,
or if A doesn''t uniquely own that B object but needs it to exist after
the constructor has completed, accept a std::tr1::shared_ptr<B> (or
boost::shared_ptr<B>) or similar and store it as a member of A.
For example, in the case of copy constructors, I would find odd to
learn that for objects o1 and o2 of certain class O, where o1 was
constructed from o2, o1 requires o2 to exist beyond the call to o1''s
constructor.
I would like to extend the discussion to other types of dependencies,
for example, when A declares a member function that takes an object of
class B as a parameter.
The same idioms apply in these two cases, methinks.
Cheers! --M
Roland Pibinger wrote:
No. This setting seems to be an anti-idiom. When A depends on B then
let A create B in the constructor:
class A {
B b;
public:
A (int i) : b(i) {}
...
};
Google for "construction encapsulation".
(And it''s heartwarming to see how, each year, this newsgroup gets posts
detracting from the good memes of yesteryear as if they were "myths", or
"anti-idioms"...)
--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
这篇关于对象生命周期要求公约的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
