Cyclic包含隐藏C ++头文件中的实现细节的技巧

问题描述 投票：3回答：4

我试图找到一种干净的方法来分离大项目中C ++头文件中的实现细节，以实现更好的信息隐藏并减少构建时间。 C ++的问题在于，每次更改私有成员声明时，都必须重建依赖类。

这是我提出的解决方案。这有什么好处吗？

基本的想法是在标题中有条件地包含cpp文件的一部分。此部分包含实现声明，仅在实现文件包含标头时包含。在外部类的情况下，此详细信息将从标题中排除。所以客户端和实现看到两个不同版本的头文件。内部声明更改不会影响客户端（不编译依赖类），标头不会包含私有详细信息。

这是实施：

HEADER

#pragma once

class Dependency
{
public:
    Dependency(void);
    ~Dependency(void);
    void Proc(void);

//PRIVATE Implementaion details stays private
#ifdef Dependency_PRIVATE_IMPELEMENTATION
    #define Dependency_PRIVATE_MODE 1   
        #include "Dependency.cpp"
    #undef Dependency_PRIVATE_MODE
#endif 
};

CPP

#define Dependency_PRIVATE_IMPELEMENTATION
#include "Dependency.h"
#undef Dependency_PRIVATE_IMPELEMENTATION

#ifdef Dependency_PRIVATE_MODE
private:
    int _privateData;
#else

#include <iostream>

Dependency::Dependency(void)
{
//This line causes a runtime exception, see client
    Dependency::_privateData = 0;
}

Dependency::~Dependency(void)
{
}

void Dependency::Proc(void)
{
    std::cout << "Shiny happy functions.";
}

#endif

客户

#include "stdafx.h"
#include "Dependency.h"

#pragma message("Test.Cpp Compiled")

int _tmain(int argc, _TCHAR* argv[])
{
    Dependency d;
    d.Proc();

    return 0;
//and how I have a run time check error #2, stack around d ?!!

}
c++ include implementation
4个回答
5
投票

真的，这是一个非常有趣的问题。管理依赖关系对于大型项目非常重要，因为构建时间的增加甚至可以使最简单的更改变得令人生畏......当它发生时，人们会尝试破解它以避免重建（tm）。

不幸的是，它不起作用。

标准明确指出，出现在不同翻译单元（粗略地说，文件）中的类定义应遵循一个定义规则（参见§3.2一个定义规则[basic.def.odr]）。

为什么？

在某种程度上，问题是阻抗问题。类的定义包含有关类ABI（应用程序二进制接口）的信息，最值得注意的是，这样的类是如何在内存中布局的。如果您在各种翻译单元中具有相同类的不同布局，那么在完全放置它时，它将无法工作。就像一个TU说德语和另一个韩语。他们可能试图说同样的话，他们只是不会互相理解。

那么？

有几种方法可以管理依赖项。主要想法是你应该尽可能地提供“轻”标题：

  • 包括尽可能少的东西。您可以转发声明：显示为参数的类型或返回函数声明，通过引用或指针传递但未使用的类型。
  • 隐藏实施细节

嗯......这是什么意思：x？

让我们选一个简单的例子，好吗？

#include "project/a.hpp" // defines class A
#include "project/b.hpp" // defines class B
#include "project/c.hpp" // defines class C
#include "project/d.hpp" // defines class D
#include "project/e.hpp" // defines class E

namespace project {

  class MyClass {
  public:
    explicit MyClass(D const& d): _a(d.a()), _b(d.b()), _c(d.c()) {}
    MyClass(A a, B& b, C* c): _a(a), _b(b), _c(c) {}

    E e() const;

  private:
    A _a;
    B& _b;
    C* _c;
  }; // class MyClass

} // namespace project

这个标题包含5个其他标题，但实际需要多少个？

  • a.hpp是必要的，因为_a类型的A是该类的属性
  • b.hpp没有必要，我们只提到B
  • c.hpp没有必要，我们只有一个指向C的指针
  • d.hpp是必要的，我们称之为D的方法
  • e.hpp没有必要，它只是作为回报出现

好的，让我们清理一下吧！

#include "project/a.hpp" // defines class A
#include "project/d.hpp" // defines class D

namespace project { class B; }
namespace project { class C; }
namespace project { class E; }

namespace project {

  class MyClass {
  public:
    explicit MyClass(D const& d): _a(d.a()), _b(d.b()), _c(d.c()) {}
    MyClass(A a, B& b, C* c): _a(a), _b(b), _c(c) {}

    E e() const;

  private:
    A _a;
    B& _b;
    C* _c;
  }; // class MyClass

} // namespace project

我们可以做得更好吗？

好吧，首先我们可以看到我们只在类的构造函数中调用D上的方法，如果我们将D的定义移出标题，并将其放在.cpp文件中，那么我们就不需要包含d.hpp了更长！

// no need to illustrate right now ;)

但是...... A是什么？

通过注意仅仅握住指针不需要完整的定义，可以“作弊”。这被称为实现指针（简称pimpl）。它会减少运行时间以获得更轻的依赖性，并为类增加了一些复杂性。这是一个演示：

#include <memory> // don't really worry about std headers,
                  // they are pulled in at one time or another anyway

namespace project { class A; }
namespace project { class B; }
namespace project { class C; }
namespace project { class D; }
namespace project { class E; }

namespace project {

  class MyClass {
  public:
    explicit MyClass(D const& d);
    MyClass(A a, B& b, C* c);
    ~MyClass(); // required to be in the source file now
                // because for deleting Impl,
                // the std::unique_ptr needs its definition

    E e() const;

  private:
    struct Impl;
    std::unique_ptr<Impl> _impl;
  }; // class MyClass

} // namespace project

和相应的源文件，因为这是有趣的事情发生：

#include "project/myClass.hpp" // good practice to have the header included first
                               // as it asserts the header is free-standing

#include "project/a.hpp"
#include "project/b.hpp"
#include "project/c.hpp"
#include "project/d.hpp"
#include "project/e.hpp"

struct MyClass::Impl {
  Impl(A a, B& b, C* c): _a(a), _b(b), _c(c) {}

  A _a;
  B& _b;
  C* _c;
};

MyClass::MyClass(D const& d): _impl(new Impl(d.a(), d.b(), d.c())) {}
MyClass::MyClass(A a, B& b, C* c): _impl(new Impl(a, b, c)) {}
MyClass::~MyClass() {} // nothing to do here, it'll be automatic

E MyClass::e() { /* ... */ }

好吧，那就是低调和坚韧不拔。进一步阅读：

  • Law of Demeter：避免不得不在序列中调用多个方法（a.b().c().d()），这意味着你有漏洞抽象，并强迫你包括整个世界做任何事情。相反，你应该调用a.bcd()来隐藏你的细节。
  • 将代码分离为模块，并为每个模块提供清晰明确的接口，通常，模块中的代码应该比表面上的代码多得多（即暴露的头部）。

有许多方法可以封装和隐藏信息，您的任务才刚刚开始！

4
投票

这不起作用。如果您在私有.cpp文件中向类添加任何内容，则该类的用户将看到与您的实现认为不同的类。

这不合法，在许多情况下不起作用。 KDE有一篇很棒的文章，说明你可以和不能在C ++中改变什么以保持ABI兼容性：Binary Compatibility Issues。如果您使用“隐藏”实现中断任何一项，那么您将打破用户。

看看pimpl idiom是一种相当常见的方式来做你想要达到的目标。

2
投票

看看Opaque_pointer pattern（又名pImpl）

该模式通常用于Class希望隐藏内部实现时，但也具有内部和私有结构的更改不会创建重新编译的好处，因为维护了二进制调用兼容性。

以任何其他方式执行此操作的问题是，当您更改类定义中的任何内容时，可能无法维护二进制兼容性，因此必须重新编译所有软件。

看起来您的解决方案是尝试这样做，但是您应该使用（void *）而不是int，以确保软件在不同平台上的32位和64位编译器上正确编译 - 并且只需使用不透明指针的烹饪书例子。

2
投票

这不行。你可以很容易地看到它，因为sizeof(Dependency)的实现和客户端是不同的。客户端基本上看到一个不同的类，访问内存中的不同位置，一切都搞砸了！

遗憾的是，如果更改类，则无法阻止重建依赖文件。但是，您可以隐藏实现细节，如下所示：

Header:

class privateData;

class Dependency
{
private:
    privateData *pd;
public:
    Dependency(void);
    ~Dependency(void);
    void Proc(void);
};

cpp file

#include <Dependency.h>

class privateData
{
    /* your data here */
};

Dependency::Dependency()
{
    pd = new privateData;
}
Dependency::~Dependency()
{
    if (pd)
        delete pd;
}
void Dependency::Proc()
{
    /* your code */
}

请注意，这不适合您复制粘贴。这只是为了给你这个想法。可能缺少此错误检查或此用法隐含的代码。其中一个是复制构造函数，以防止浅拷贝。

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.