使用C++模块时,是否有任何理由将函数声明(.hpp文件)与其定义(.cpp文件)分开？

Question

我习惯于编写没有模块的代码,其中头文件包含函数声明,如:

// foo.h 
class Foo
{
    void bar();
};

并且相应的.cpp文件包含以下定义:

// foo.cpp
#include "foo.h"

void Foo::bar()
{
    // ...
}

据我所知,这样做是为了减少编译时间并减少依赖性.当使用模块时,这仍然适用吗？将类放在单个文件中的定义与Java和C#的定义方式一样快吗？如果是这种情况,使用模块时是否需要.hpp和.cpp文件？

Answer 1

我所知道的唯一原因，就像目前的模块提案一样，是处理循环接口依赖关系。

如果程序由模块组成，并且没有将函数声明与定义分开，则所有模块文件都将是模块接口（与模块实现相反）。如果要将它们与头文件和代码文件进行比较，可以将模块接口视为头 (.hpp) 文件，将模块实现视为代码 (.cpp) 文件。

不幸的是，模块提案不允许循环模块接口依赖。并且由于您的程序现在完全由模块接口组成，因此您将永远无法拥有两个以任何方式相互依赖的模块（这可能会proclaimed ownership在未来的声明中得到改进，但目前不支持） . 解决循环模块接口依赖的唯一方法是将声明和定义分开，并将循环导入放在模块实现文件中，相对于循环模块接口依赖，允许循环模块实现依赖。

下面的代码提供了一个不分离声明和定义就无法编译的情况示例：

Foo module file

export module Foo;

import module Bar;

export namespace Test {
    class Foo {
    public:
        Bar createBar() {
            return Bar();
        }
    };
}

Bar module file

export module Bar;

import module Foo;

export namespace Test {
    class Bar {
    public:
        Foo createFoo() {
            return Foo();
        }
    };
}

本文展示了如何在proclaimed ownership声明可用的情况下解决此问题的示例。本质上，它归结为分离声明和定义。

在一个完美的世界中，编译器将能够处理这种情况，但唉，据我所知，当前提议的模块实现不支持它。

Answer 2

这里有一个很好的讨论解释了模块的想法。

简而言之，你是对的，头文件和实现文件之间的分离将不再需要。该#include指令将被指令替换import，并且在编译时模块将提供所需的信息，否则这些信息将包含在包含的头文件中。