使用智能指针进行继承的 pimpl
Posted
技术标签:
【中文标题】使用智能指针进行继承的 pimpl【英文标题】：pimpl with inheritance using smart pointer 【发布时间】：2016-02-04 03:22:00 【问题描述】：请参阅我的 PIMPL 继承实现。在派生类中，DerivedImpl 继承自 BaseImpl。
问题： 指向 Impl 的指针是否应该只在基类中定义，如以下代码？如果是这样，每次我需要使用基指针时，我都必须将其转换为派生类型。但是，根据分析结果，静态转换 shared_ptr 看起来很昂贵，因为这种转换被广泛使用。而且 cast 函数不能内联在 header 中，因为它在那里不完整。
也许我犯了一些错误。或者使用智能指针有更好的实现吗？
// Base.h
class BaseImpl; // pre-declaration
class Base
public:
Base();
explicit Base(BaseImpl* ptr);
~Base();
protected:
std::shared_ptr<BaseImpl> d_Ptr;
;
// baseimpl.h
class BaseImpl
double mDate;
;
// Derived.h
#include "Base.h"
class DerivedImpl;
class Derived :
public Base
public:
Derived();
~Derived();
std::shared_ptr<DerivedImpl> d_func();
const std::shared_ptr<DerivedImpl> d_func() const;
;
// Derived.cpp
#include "Derived.h"
#include "DerivedImpl.h"
Derived::Derived() : Base(new DerivedImpl())
Derived::~Derived()
std::shared_ptr<DerivedImpl> Derived::d_func()
return std::static_pointer_cast<DerivedImpl>(d_Ptr);
const std::shared_ptr<DerivedImpl> Derived::d_func() const
return std::static_pointer_cast<DerivedImpl>(d_Ptr);
【问题讨论】：
你真的需要从d_func返回一个shared_ptr吗？
我想不出任何情况下为一组类实例共享动态分配的实现是有意义的。你应该只使用unique_ptr。
@immibis 我不确定。如果 d_func 返回原始指针，是否存在内存泄漏风险？ （例如 d_func()->aMemberFunc() 抛出）
@YohWang 如果d_func()->aMemberFunc() 抛出，那么这与任何内存泄漏无关。内存泄漏是指您的程序分配了某些东西而忘记释放它。
【参考方案1】：
我假设你想要你所描述的，模实现细节：
公共类的继承层次结构。
基于实现类的相应继承层次。
实现对全局命名空间和/或宏的可能使用应仅限于单独编译的单元。
这是一个问题，派生类特定初始化，例如弹出在 C++ 类中包装一组低级 GUI 小部件时。在许多其他情况下也是如此。有多种可能的解决方案，但您目前的解决方案是通过基类构造函数将指向实现的指针向上传递到最顶层的基类，在那里它被提供给派生类。
不过，你不确定这是个好主意：
” 指向 Impl 的指针是否应该像下面的代码一样只定义在基类中？
是的，理想情况下应该这样做，因为这种方法可确保始终完全构造可用的基类实例。这就是 C++ 构造函数的基本思想。在初始化（例如基类子对象）之后，您要么手头有一个工作对象，要么什么都没有，即异常或终止。
但是，这种方法可以解决两个问题：
如何高效提供派生类实现指针？
如何从基类实现派生实现？
后一个问题很容易通过为实现设置单独的头文件来解决。请记住，信息隐藏的目的不是使这些类的源代码在物理上不可访问，尽管这仍然是可能的。但要避免污染全局命名空间，以及宏地。
第一个问题，也就是你真正要问的问题，
” 根据分析结果，静态转换 shared_ptr 看起来很昂贵，因为这种转换被广泛使用
真的不是问题。
向下转换函数只需要在代码的实现部分可以访问，并且它们的源代码可用并且可以内联调用。
最后，只是建议，你应该使用unique_ptr，或者没有智能指针，或者可能是一个自动克隆的智能指针，而不是shared_ptr，作为实现指针。因为您通常不希望公共类实例的副本与原始实例共享其实现。除了实现没有状态的情况外，在这种情况下动态分配它并没有多大意义。
例子：
Base.hpp：#pragma once
#include <memory>
namespace my
using std::unique_ptr;
class Base
protected:
class Impl;
private:
unique_ptr<Impl> p_impl_;
protected:
auto p_impl() -> Impl* return p_impl_.get();
auto p_impl() const -> Impl const* return p_impl_.get();
Base( unique_ptr<Impl> p_derived_impl );
public:
auto foo() const -> char const*;
~Base();
Base();
;
// namespace my
#pragma once
#include "Base.hpp"
class my::Base::Impl
public:
auto virtual foo() const -> char const* return "Base";
virtual ~Impl()
;
#include "Base.Impl.hpp"
#include <utility> // std::move
using std::move;
using std::unique_ptr;
auto my::Base::foo() const
-> char const*
return p_impl()->foo();
my::Base::~Base()
my::Base::Base()
: p_impl_( new Impl() )
my::Base::Base( unique_ptr<Impl> p_derived_impl )
: p_impl_( move( p_derived_impl ) )
#pragma once
#include "Base.hpp"
namespace my
class Derived
: public Base
protected:
class Impl;
Derived( unique_ptr<Impl> p_morederived_impl );
private:
auto p_impl() -> Impl*;
auto p_impl() const -> Impl const*;
public:
~Derived();
Derived();
;
// namespace my
#pragma once
#include "Base.Impl.hpp"
#include "Derived.hpp"
class my::Derived::Impl
: public my::Base::Impl
public:
auto foo() const -> char const* override return "Derived";
;
#include "Derived.Impl.hpp"
#include <utility> // std::move
using std::move;
using std::unique_ptr;
inline auto my::Derived::p_impl() -> Impl*
return static_cast<Impl*>( Base::p_impl() );
inline auto my::Derived::p_impl() const -> Impl const*
return static_cast<Impl const*>( Base::p_impl() );
my::Derived::~Derived()
my::Derived::Derived()
: Base( unique_ptr<Impl>( new Impl() ) )
my::Derived::Derived( unique_ptr<Impl> p_morederived_impl )
: Base( move( p_morederived_impl ) )
#include "Derived.hpp"
#include <iostream>
using namespace std;
auto main() -> int
wcout << my::Derived().foo() << endl;
技术性：在Derived 类中，向下转换函数是private，以防止它们被更多派生类直接使用。这是因为实现是inline，并且应该在使用它们的每个翻译单元中进行相同的定义。与其将其划分为更多的头文件，更多的派生类应该/可以直接从Base 实现向下转换，就像Derived 所做的那样。
【讨论】：
这就是我需要的。我有两个担忧。 1. 暴露原始指针安全吗？我需要编写更多的异常处理代码吗？ 2.我认为内联函数应该在header中定义。但是 static_cast 无法完成，因为 Impl 仅在此处前向声明。谢谢！ 我认为原始指针的 static_cast 很便宜。 static_pointer_cast 的开销来自 shared_ptr 的副本。对于我的问题 2，我们可以通过使用 reinterpret_cast 而不是 static_cast 将向下转换放入标题中作为内联。 原始指针不利于所有权，但它们仅用于引用事物是可以的。只要可以证明所引用的事物的生命周期超过了原始指针的使用时间，在这种情况下您默认会得到（但不要将原始指针存储在任何地方）。重新内联函数与头文件，语言规范与文件非常无关，它根本不处理文件。然而，这两个特定的函数在技术上不需要是成员函数。我选择让它们成为更简单的符号的成员，但它们可以只是内联独立函数。 static_cast 很便宜是的：它通常是无操作的，尽管在某些情况下它可以调整地址。 reinterpret_cast 很少是一个解决方案，而是一个问题。它就像一条有毒的鱼，有时出于饮食原因绝对需要，但最好小心，并且通常避免它。 非常感谢您耐心的回答。我今天学到了很多。【参考方案2】：我认为您通过将BaseImpl 的详细信息暴露给Base 的用户，而不仅仅是从Base 派生的类，而是向Base 的所有用户公开，从而破坏了Pimpl idiom 的目的。出于完全相同的原因，DerivedImpl 也需要隐藏。
我推荐以下：
// Base.h
class Base
public:
Base();
virtual ~Base();
// Add copy constructor and copy assignment operator too.
// Follow the rule of Three/rule of Five.
// Class that holds the implementation details of Base.
class Impl;
private:
// Never expose the details of Impl
// and never expose d_Ptr to clients.
Impl* d_Ptr;
;
// Base.cpp
class Base::Impl
// Add the necessary member variables and functions to facilitate
// Base's implementation
;
Base() : d_Ptr(new Impl)
~Base()
delete d_Ptr;
// Derived.h
#include "Base.h"
class Derived : public Base
public:
Derived();
~Derived();
// Add copy constructor and copy assignment operator too.
// Follow the rule of Three/rule of Five.
// Class that holds the implementation details of Derived.
// Has no relation to Base::Impl
class Impl;
private:
// Never expose the details of Impl
// and never expose d_Ptr to clients.
Impl* d_Ptr;
;
// Derived.cpp
class Derived::Impl
// Add the necessary member variables and functions to facilitate
// Derived's implementation
;
Derived() : d_Ptr(new Impl)
~Derived()
delete d_Ptr;
【讨论】：
@Cheersandhth.-Alf，不推荐。我删除了它们。 @RSahu 在每个派生类中都有一个指向 Impl 的指针看起来效率不高。内存将被重复分配以构造一个 Derived 类（您的代码中有两个“新 Impl”。）并且 DerivedImpl 可能从 BaseImpl 继承一些成员。 @YohWang，当您使用 Pimpl 习惯用法时，您会承担额外的分配和释放开销。你可以做你想做的事，但是，IMO，它违背了 Pimpl 成语背后的原则。 @RSahu，有时 impl 包含一个巨大的数据成员。（我的案例是一个科学库）。如果我接受开销，如何通过Impl实现继承和多态。或者从 Base::Impl 派生 Derived::Impl 也违背了 Pimpl 的原则。 @YohWang，如果您觉得需要从Base::Impl 继承Derived::Impl，我会说您的设计存在缺陷。 Impl 是否拥有需要公开的巨大数据成员，您的类不适合 Pimpl 习惯用法。如果Base::Impl 的数据需要暴露给Derived::Impl，最好不要使用Pimpl 成语。将所有数据放入Base，并通过简单的访问器和修饰符函数使数据可访问。【参考方案3】：
过时的讨论，但是.. 我一直在思考在类层次结构中使用 pimpl 习惯用法的想法，但我不明白如果不向 impl 添加多态行为，它是如何实用的。鉴于 pimpl 成语的动机之一是避免使用 vtable，似乎一旦将多态性添加到 impls 中，您就不再使用经典意义上的 pimpl 成语了。相反，它现在更像是一种桥接模式。它可以解决类似的问题，但它的动机有点不同。
【讨论】：
以上是关于使用智能指针进行继承的 pimpl的主要内容，如果未能解决你的问题，请参考以下文章