问题标签 [translation-unit]

为什么我还必须在 .cpp 文件中写入静态 constexpr 的定义？

我正在使用 C++11 开发CLion 2018.3.4 。

我试图在这里和那里弄乱代码，但我想不出答案。

在翻译单元中，静态 constexpr 成员在声明时被初始化，因此在头文件中。虽然这应该足够了，但链接器并不认为这是一个正确的定义，为了使该成员在所有翻译单元中真正唯一，我们必须在 .cpp 文件中提供一个定义。

//.h 文件

//.cpp 文件

我认为，如果我们删除 .cpp 文件中的定义，则可以在其他翻译单元中重新定义该成员。

额外的小问题： 是否正确地说，在 .cpp 文件中写入的成员实际上是全局且恒定的，而在 .cpp 文件中没有写入的成员仍然是全局但不是静态的？

我不完全了解确切的过程以及为什么会发生这种情况。

（我在某处读到在 C++ 17 中这有一些演变，但我正在研究 C++ 11）

我有一些可以检查的课程。实现这一点的代码在头文件中声明了一个函数模板，并将其专门用于不同的源文件：

这段代码是这样使用的：

这工作得很好。当我添加另一个Class3可以检查的类时，我不需要触摸头文件，因为它定义了一个非常宽的接口。如果我忘记实现 的check函数Class3，链接器会用错误消息提醒我。

我的问题是：这种行为是有保证的，还是我的代码是靠运气工作的？我正在使用 Visual Studio。

如果我想特化我的函数模板，我不应该在头文件中声明我的所有特化吗？

在 CI 中可以有一个结构和一些在头文件中声明的公共函数，而一些“私有”函数可以在源文件中声明为静态。例如：

foo.h

foo.c

在这种情况下func2是内部链接的。这对 C++ 类方法可行吗？如果我写：

foo.hpp

func2仍将与外部链接。有没有办法让它内部保留它在结构内？

可以跨所有翻译单元进行#define 或类似的预处理器定义吗？

标头实现对于非常小的库很有用，因为所有代码都可以包含和分布在具有以下结构的单个标头中：

然而，这种结构要求用户IMPLEMENT_LIBRARY在标头仅包含在他们的一个翻译单元中之前进行定义，这意味着它不能放在用户的头文件中，并且对于不完全熟悉 C++ 编译的人来说可能有点混乱规则。

如果有一种方法可以IMPLEMENT_LIBRARY跨所有 TU 进行定义，则可以使用以下命令自动完成

是否存在这样的机制，或者当前的单头系统是否与它将获得的一样好？

我又在为 Boost.Spirit.X3 苦苦挣扎。

我有几个逻辑解析器组（语句、表达式等），每个解析器都由几个文件表示：

• group.hpp- 包含“外部”使用的解析器typedef的 sBOOST_SPIRIT_DECLARE和extern变量声明
• group_def.hpp- 包括前一个并包含解析器的实际定义BOOST_SPIRIT_DEFINE，等等。
• group.cpp- 包括前一个并包含显式模板实例化（通过BOOST_SPIRIT_INSTANTIATE）

基本上，它或多或少遵循官方教程中提出的结构。唯一的区别是我的语法要复杂得多，所以我试图把它分成几个翻译单元。然后将所有这些 TU 编译到一个库中，然后将其链接到主可执行文件。

我试图在这里做一个“最小”的例子（活在 Wandbox 上），因为在这里列出所有文件会很不方便。 由于一些未解决的外部因素，它不起作用，所以，很可能，我错误地实例化了一些东西，但我已经为此花了大约一周的时间，所以我很绝望，不觉得我能我自己来处理这个。

几个问题和答案：

为什么我更喜欢每个“组”使用三个文件？

首先，因为我试图以这样一种方式制作它，即我不想在任何小的更改上重新编译所有内容（不确定我是否成功了），所以这个想法somegroup.hpp只是一个带有声明的“轻量级”标题，somegroup_def.hpp是带有定义的标题，somegroup.cpp仅用于创建翻译单元。

其次，我拆分_def.hpp，.cpp因为我还将这些_def.hpp文件直接包含到测试中，我不仅涵盖extern解析器，还涵盖“内部”辅助解析器。

为什么我要使用extern变量？

我也尝试使用返回解析器的函数（类似于教程中的完成方式）。基本上，这就是它的实现方式和现在的工作方式。我不喜欢它，因为例如，给定一个解析器lang::parser::import，我必须给一个函数另一个名称（lang::parser::import_）或将它放在另一个名称空间中（即lang::import）。此外，我喜欢直接使用解析器的方式，它是如何在 Spirit 本身中完成的（即不带括号：importvs import_()）。

我的实际问题如下：

• 如果我想将解析器分布在多个翻译单元上，如何正确组织结构？
• 我在上面的代码示例中究竟遗漏了什么，所以它没有链接？

我将不胜感激任何帮助。

给定一个类模板，编译时间太长。在开发和调试期间，我想通过将成员函数的定义分成单独的翻译单元来减少编译时间。只是为了完全专业化（这也是为了减少编译时间）。

是否可以在 C++ 中通过将类模板完全专业化的成员函数的定义放入单独的 TU 中来分离它们？

template<> void A<smth>::f()或者void A<smth>::f()在尝试中什么都不做。我无法解决链接时间错误。

使类模板的显式实例化声明（即extern template class...）可见（或不可见）（连同删除void A<smth>::f()）到定义成员函数的 TU 中，也没有给出任何结果。

C# 中的程序集是否类似于 C++ 中的翻译单元？

在 C++ 中，一个 .h、.cpp 文件称为翻译单元（预处理完成状态）。同样，是否有一个 .cs 文件在 C# 中称为程序集？

还是与 C++ 低级语言中的汇编相同？

头文件是翻译单元吗？如果我将 static 关键字添加到头文件中的变量，我可以在我的 .c 或 .cpp 文件中调用该变量吗？谢谢。

我总是这样安排我的 C++ 头文件和源文件：

程序.h

程序.cpp

主文件

但我最近发现以其他方式排列它们很常见：

程序.h

程序.cpp

主文件

我发现第一种方法更方便，那么有什么理由让我更喜欢第二种方法而不是第一种方法？

我需要禁用某个头文件中的所有警告，并且只禁用该文件。我的编译器版本是g++-4.8. 我必须使用那个编译器。

我查看了该编译器的文档： g++-4.8 documentation support for System-Headers

这个已经写完了：

#warning在 GCC 处理系统标头时，所有警告（由 生成的警告除外）都会被抑制。系统标头中定义的宏在扩展时不受一些警告的影响。

还有一个指令 ，#pragma GCC system_header它告诉 GCC 将当前包含文件的其余部分视为系统头，无论它是在哪里找到的。文件中 之前的代码#pragma不会受到影响。#pragma GCC system_header在主源文件中无效。

由于英语是我的第二语言，我不清楚最后一句话是什么意思。

我想禁用整个单个头文件中的所有警告。该头文件包含在许多不同的 C++ 源代码文件*.cpp中。这个头文件也被其他几个头文件*.h所包含，而那些头文件也被其他文件所包含。

我想知道，如果我将 放在#pragma GCC system_header单个头文件中，该#pragma指令的效果是否会转移到包含该头文件的任何文件中？因为我不想禁用包含此头文件的文件中的任何警告。我只想对在该头文件中定义的结构禁用警告。

所以换句话说，效果是#pragma GCC system_header适用于整个翻译单元（我不想要那个）还是只适用于文本编辑器中的单个头文件？