我有在构造函数中创建其他子对象的对象,传递'this‘,这样子对象就可以保存回其父对象的指针。我在编程中广泛使用boost::shared_ptr作为std::auto_ptr或原始指针的更安全的替代方案。因此,子进程会有诸如shared_ptr<Parent>
之类的代码,boost提供了父进程可以提供给子进程的shared_from_this()
方法。
我的问题是,shared_from_this()
不能在构造函数中使用,这并不是真正的犯罪,因为无论如何都不应该在构造函数中使用'this‘,除非你知道自己在做什么,并且不介意限制。
谷歌的C++风格指南states指出,构造函数只应将成员变量设置为其初始值。任何复杂的初始化都应该在显式的Init()方法中进行。这解决了“This -in-constructor”问题以及其他一些问题。
让我感到困扰的是,现在使用您的代码的人必须记住,每次构造您的对象时都要调用Init()。我能想到的唯一方法是通过断言,在每个成员函数的顶部已经调用了Init(),但这是乏味的编写和繁琐的执行。
在这个过程中,有没有什么习惯用法可以解决这个问题?
发布于 2010-03-25 02:53:12
谷歌的C++编程指南一次又一次地受到批评。理所当然地如此。
只有当它隐藏在包装类之后时,我才会使用两阶段初始化。如果手动调用初始化函数可以工作,我们仍然可以用C和C++编程,它的构造函数永远不会被发明出来。
发布于 2010-03-25 03:21:14
根据情况,这可能是共享指针不会添加任何东西的情况。只要生命周期管理有问题,就应该随时使用它们。如果保证子对象的生命周期比父对象的生命周期短,我认为使用原始指针没有问题。例如,如果父对象创建并删除子对象(其他人都不会这样做),那么谁应该删除子对象就不存在问题了。
发布于 2010-03-25 03:00:19
需要复杂构造的对象听起来像是工厂的工作。
定义一个接口或抽象类,一个不能构造的类,再加上一个自由函数,它可能带有参数,返回一个指向接口的指针,但在场景后面会注意到复杂性。
你必须从你的类的最终用户必须做什么的角度来考虑设计。
https://stackoverflow.com/questions/2510521
复制相似问题