思考时间 - 为什么要分割文件？

Question

思考时间 - 为什么要分割文件？

正如标题所示，我遇到的最终问题是多个定义链接器错误。我实际上已经修复了问题，但我没有以正确的方式解决问题。在开始之前，我想讨论将类文件拆分成多个文件的原因。我试图把所有可能的场景放在这里 - 如果我错过任何一个，请提醒我，我可以做出改变。希望以下是正确的：

原因1 节省空间：

您有一个包含所有类成员的类声明的文件。您可以在此文件周围放置#include防护（或#pragma一次），以确保在#include包含在源文件中的两个不同头文件中的文件时不会发生冲突。您可以使用此类中声明的任何方法的实现来编译单独的源文件，因为它会从源文件中加载许多行代码，这会清除一些内容并为您的程序引入一些顺序。

示例：如您所见，可以通过将类方法的实现拆分为不同的文件来改进以下示例。（.cpp文件）

// my_class.hpp
#pragma once

class my_class
{
public:
    void my_function()
    {
        // LOTS OF CODE
        // CONFUSING TO DEBUG
        // LOTS OF CODE
        // DISORGANIZED AND DISTRACTING
        // LOTS OF CODE
        // LOOKS HORRIBLE
        // LOTS OF CODE
        // VERY MESSY
        // LOTS OF CODE
    }

    // MANY OTHER METHODS
    // MEANS VERY LARGE FILE WITH LOTS OF LINES OF CODE
}

原因2 要防止多个定义链接器错误：

也许这就是为什么要从声明中拆分实现的主要原因。在上面的示例中，您可以将方法主体移动到类外部。这将使它看起来更清洁和结构化。但是，根据此question，上面的示例具有隐式inline说明符。将实现从类中移动到类外部（如下例所示）将导致链接器错误，因此您可以内联所有内容，或将函数定义移动到.cpp文件。

示例：_如果不将函数定义移动到.cpp文件或将函数指定为内联，则下面的示例将导致“多个定义链接器错误”。

// my_class.hpp
void my_class::my_function()
{
    // ERROR! MULTIPLE DEFINITION OF my_class::my_function
    // This error only occurs if you #include the file containing this code
    // in two or more separate source (compiled, .cpp) files.
}

解决问题：

//my_class.cpp
void my_class::my_function()
{
    // Now in a .cpp file, so no multiple definition error
}

或者：

// my_class.hpp
inline void my_class::my_function()
{
    // Specified function as inline, so okay - note: back in header file!
    // The very first example has an implicit `inline` specifier
}

原因3 您想再次节省空间，但这次您正在使用模板类：

如果我们正在使用模板类，那么我们就无法将实现移动到源文件（.cpp文件）。目前，（我假设）标准或当前编译器都不允许这样做。与上面 Reason 2 的第一个示例不同，我们允许将实现放在头文件中。根据这个question，原因是模板类方法也有隐含的inline说明符。那是对的吗？（这似乎有道理。）但似乎没有人知道我刚引用的问题！

那么，以下两个例子是否相同？

// some_header_file.hpp
#pragma once

// template class declaration goes here
class some_class
{
    // Some code
};

// Example 1: NO INLINE SPECIFIER
template<typename T>
void some_class::class_method()
{
    // Some code
}

// Example 2: INLINE specifier used
template<typename T>
inline void some_class::class_method()
{
    // Some code
}

如果您有一个模板类头文件，由于您拥有的所有功能而变得庞大，那么我相信您可以将函数定义移动到另一个头文件（通常是.tpp文件？）然后{ {1}}在包含类声明的头文件的末尾。但是，您不得在其他任何地方包含此文件，因此#include file.tpp而不是.tpp。

我假设您也可以使用常规类的内联方法执行此操作？这也允许吗？

提问时间

所以我在上面做了一些陈述，其中大部分与源文件的结构有关。我认为我所说的一切都是正确的，因为我做了一些基础研究并“发现了一些东西”，但这是一个问题，所以我不确定。

归结为，您将如何在文件中组织代码。我想我已经想出了一个永远有效的结构。

这是我想出的。（这是“Ed Bird的班级代码文件组织/结构标准”，如果你愿意的话。不知道它是否会非常有用，那就是问题。）

1：在.hpp文件中声明类（模板或其他），包括所有方法，朋友功能和数据。
2：在.hpp文件的底部，.hpp一个#include文件，其中包含任何.tpp方法的实现。创建inline文件并确保将所有方法指定为.tpp。
3：所有其他成员（非内联函数，友元函数和静态数据）应在inline文件中定义，.cpp为#include在顶部的文件，以防止像“类ABC尚未声明”的错误。由于此文件中的所有内容都具有外部链接，因此程序将正确链接。

这样的标准是否存在于工业中？我会在所有情况下提出标准吗？

Answer 1

你的三点听起来是正确的。这是做事情的标准方式（虽然之前我没有看过.tpp扩展名，通常是.inl），虽然我个人只是在头文件的底部放入内联函数而不是单独的文件。

以下是我安排文件的方式。我省略了简单类的前向声明文件。

MyClass的-fwd.h

#pragma once

namespace NS
{
class MyClass;
}

myclass.h

#pragma once
#include "headers-needed-by-header"
#include "myclass-fwd.h"

namespace NS
{
class MyClass
{
    ..
};
}

myclass.cpp

#include "headers-needed-by-source"
#include "myclass.h"

namespace
    {
    void LocalFunc();
}

NS::MyClass::...

根据喜好用标题保护替换pragma ..

这种方法的原因是减少了头部依赖性，这减慢了大型项目中的编译时间。如果您不知道，可以转发声明一个类以用作指针或引用。只有在构造，创建或使用类的成员时才需要完整的声明。

这意味着使用该类的另一个类（通过指针/引用获取参数）只需要在其自己的头中包含fwd头。然后将完整标头包含在第二个类的源文件中。这大大减少了你拉入一个大头时所需的垃圾数量，它会拉入另一个大头，这会吸引另一个......

下一个提示是未命名的命名空间（有时称为匿名命名空间）。这只能出现在源文件中，它就像一个只对该文件可见的隐藏命名空间。您可以在此处放置仅由源文件使用的本地函数，类等。如果您在两个不同的文件中创建具有相同名称的内容，则可以防止名称冲突。（例如，两个本地函数F可能会给链接器错误。）

Answer 2

将接口与实现分开的主要原因是，当实现中的某些内容发生更改时，您不必重新编译所有代码;您只需重新编译已更改的源文件。

至于“声明课程（模板或其他）”，template 不 a class。 template是创建类的模式。但更重要的是，您定义标题中的类或模板。类定义包括其成员函数的声明，非inine成员函数在一个或多个源文件中定义。内联成员函数和所有模板函数应该在标题中定义，无论你喜欢哪种直接定义和#include指令的组合。

Answer 3

这样的标准是否存在于行业中？

是。然后，在工业中也可以找到与您表达的标准截然不同的编码标准。毕竟，你所说的是编码标准，编码标准从优秀到坏到丑。

我会在所有情况下提出标准吗？

绝对不是。例如，

template <typename T> class Foo {
public:
   void some_method (T& arg);
...
};

这里，类模板Foo的定义不知道关于该模板参数T的事情。如果对于某些类模板，方法的定义根据模板参数而有所不同？你的规则＃2在这里不起作用。

另一个例子：如果相应的源文件很大，千行或更长，该怎么办？有时在多个源文件中提供实现是有意义的。有些标准极端地规定了每个文件的一个功能（个人意见：Yech！）。

在一千多行的另一个极端，长源文件是一个没有源文件的类。整个实现都在标题中。对于仅头部实现，有很多要说的。如果不出意外，它会简化（有时是显着的）链接问题。

将C ++类代码分成多个文件，有哪些规则？

思考时间 - 为什么要分割文件？

提问时间

3 个答案: