在 C + + 中. inl 文件的意义

在.inl 文件中使用声明有什么好处? 我什么时候需要使用相同的声明？

85894 次浏览
小开

根据我的经验。Inl 文件用于定义内联函数。当他们在一个。Inl 文件中，该文件可以包含在头中以获取内联函数，并且可以包含在。C 文件获取常规函数定义。

通过这种方式，同一个源代码可以更容易地与不支持内联函数的编译器以及支持内联函数的编译器一起工作。

它们通常用于直接的 C 代码，不常用于 C + + 代码，因为所有 C + + 编译器都支持内联函数。

小开

我相信这只是一个“头”文件包含内联代码的变数命名原则。 这样.h 文件可以包含定义，而.inl 文件包含模板所必需的内联代码。

我认为除了一个变数命名原则，没有什么比这更能说明文件的目的了

小开
最佳答案

.inl文件从不是强制性的，对编译器没有特殊意义。它只是构造代码的一种方法，为可能阅读它的人们提供一个提示。

我在两种情况下使用 .inl文件:

  • 用于内联函数的定义。
  • 函数模板的定义。

在这两种情况下，我都将函数的声明放在一个头文件中，这个头文件由其他文件包含，然后 #include是位于头文件底部的 .inl文件。

我喜欢它，因为它将接口与实现分离，并使头文件更容易阅读。如果您关心实现细节，可以打开 .inl文件并读取它。如果你不愿意，也没必要。

小开

因为没有人提起过:

使用. inl 文件来存储内联函数对于加速编译非常有用。

如果只包含声明(。H)其中需要声明，并且只包括内联实现(。Inl)在您需要它们的地方(即可能只在。中央结算系统及其他。内部文件，没有。H’s) ，它可以对你的头部依赖性产生有益的影响。

对于具有许多交互类的大型项目来说，这可能是一个重大的胜利。

小开

Nick Meyer 是正确的: 编译器不关心包含的文件的扩展名，所以类似于。“ h”，“ h”，“ h”，“ h”。“ hpp”，“ hpp”，“ hpp”，“ hpp”。我不知道。啊，啊。内，内。Inc”等是一个简单的约定，目的是明确文件应该包含哪些内容。

最好的例子是没有任何扩展名的 STL 头文件。

通常，“ . inl”文件包含 内嵌式代码(因此扩展名为“ . inl”)。

当 标题代码之间存在依赖周期时，这些文件“ . inl”文件是必需的。

例如:

// A.hpp
struct A
{
void doSomethingElse()
{
// Etc.
}


void doSomething(B & b)
{
b.doSomethingElse() ;
}
} ;

还有:

// B.hpp
struct B
{
void doSomethingElse()
{
// Etc.
}


void doSomething(A & a)
{
a.doSomethingElse() ;
}
} ;

你不可能编译它，包括使用前向声明。

然后，解决方案是将定义和实现分解为两种头文件:

  • 用于头声明/定义的 hpp
  • 头实现的 inl

它可以分解为以下例子:

// A.hpp


struct B ;


struct A
{
void doSomethingElse() ;
void doSomething(B & b) ;
} ;

还有:

// A.inl
#include <A.hpp>
#include <B.hpp>


inline void A::doSomethingElse()
{
// Etc.
}


inline void A::doSomething(B & b)
{
b.doSomethingElse() ;
}

还有:

// B.hpp


struct A ;


struct B
{
void doSomethingElse() ;
void doSomething(A & a) ;
} ;

还有:

// B.INL
#include <B.hpp>
#include <A.hpp>


inline void B::doSomethingElse()
{
// Etc.
}


inline void B::doSomething(A & a)
{
a.doSomethingElse() ;
}

这样，您可以在您自己的源代码中包含您需要的任何“ . inl”文件，并且它将工作。

同样，所包含文件的后缀名并不重要，重要的是它们的用法。


提交答案