This code is from "C++ programming language" by Bjarne Stroustrup (C.13.8.3 Point of Instantiation Binding)

And he mentions:

Here, the point of instantiation for f() is just before h(), so the g() called in f() is the global g(int) rather than the local g(double). The definition of ‘‘instantiation point’’ implies that a template parameter can never be bound to a local name or a class member.

My questions are:

1. Why should the first code work? g() is declared later, and I really get an error with G++ 4.9.2 that g isn't declared at that point.

2. extern g(double) - how this works? since return value doesn't matter in case of function overloading, then we can miss it in forward declarations?

3. the point of instantiation for f() is just before h() - why? isn't it logical that it'll get instantiated when f(2) is being called? Right where we call it, whence g(double) will be in scope already.

4. The definition of ‘‘instantiation point’’ implies that a template parameter can never be bound to a local name or a class member - Has this changed in C++14? I'm getting error with C++(G++ 4.9.2), but don't get error with C++14(G++ 4.9.2).

Suppose I have

and I want to compile one instantiation with -ffast-math (--use-fast-math for nvcc), and the other instantiation without it.

This can be achieved by instantiating each of the variants in a separate translation unit, and compiling each of them with a different command-line - with and without the switch.

My question is whether it's possible to indicate to popular compilers (*) to apply or not apply -ffast-math for individual functions - so that I'll be able to have my instantiations in the same translation unit.

Notes:

• If the answer is "no", bonus points for explaining why not.
• This is not the same questions as this one, which is about turning fast-math on and off at runtime. I'm much more modest...

(*) by popular compilers I mean any of: gcc, clang, msvc icc, nvcc (for GPU kernel code) about which you have that information.

假设我正在尝试使用Curiously Recurring Template Pattern创建自己的 boost::filesystem::path 实现：

（为简洁起见，代码不完整，但在使用 ' ' 编译时会出现问题g++ -std=c++11 -o mypath ./mypath.cpp，使用 GCC 4.8.4）

mypath.hpp：

我的路径.cpp：

当然，我发现编写的代码不会编译，因为我在隐式实例化它Separators()之后明确地专门化了它。IsSeparator()但我并不是特别想玩打地鼠的游戏，试图让我所有的方法都井井有条。

在研究关于 SO 的类似问题时，我发现其中一个接受的答案表明我可以通过仅仅声明我的专业来巧妙地解决这个问题。但...

1. 我在 mypath.cpp 中注释掉的template class PathBase<Path>;行对问题没有影响，并且
2. 感觉就像我的头文件已经用它的整个class Path : public PathBase<Path> { ... }声明声明了显式特化。

我的显式声明到底需要是什么样的？

考虑以下代码。是否保证Derived<int>::foo()会被实例化？foo()是虚拟的，由基类的非虚拟函数调用。

比如说，有一个第三方库在头文件中有以下内容：

foo.h：

在我自己的库的界面中，我应该foo为我自己的类型提供部分专业化。所以，假设我有：

xxx.h：

whereML_GLOBAL是编译器特定的可见性属性，以确保符号可用于动态链接（默认情况下，我的构建系统隐藏生成的共享库中的所有符号）。

现在，我不想透露我的实现bar，所以我使用显式模板实例化：

xxx.cpp：

当需要tpl::foo<::ml::xxx>::bar在某个消费者应用程序（我的共享库也链接到该应用程序）中实际使用此函数时，我得到符号的未定义引用错误。tpl::foo<::ml::xxx, void>::bar实际上，在生成的共享库上运行时没有任何符号nm -CD痕迹。tpl::foo<::ml::xxx, void>

到目前为止，我尝试过的是关于放置位置的不同组合ML_GLOBAL（例如，在显式模板实例化本身上，关于 GCC 明显抱怨不像 Clang）和有/没有第二个模板参数void。

问题是这是否与原始定义ML_GLOBAL由于来自第三方库而没有附加可见性属性 ( ) 的事实有关，还是我实际上在这里错过了什么？如果我没有错过任何东西，那么我真的被迫在这种情况下公开我的实现吗？[... *咳嗽* 说实话看起来更像是编译器缺陷 *咳嗽* ...]

_{从设计的角度来看，请忽略可疑的继承模式。谢谢 ：）}

考虑以下情况：

在 GCC 和 Clang 中，将其编译为独立的 TU 会引发错误：

这是 GCC 的，Clang 的类似，并且都指向struct Bar. 此外，在修复错误后 添加缺少的定义：main()

在我看来，std::unique_ptr在定义时需要正确实例化 ' 的析构函数并不正确Bar，因为它仅由Bar' 外线定义的析构函数调用。

我发现更奇怪的是，在其他所有内容之后添加定义，在它们不应该到达的地方，显然可以解决问题。

第一个片段应该是正确的，如果不是，为什么？修复它的第二个发生了什么？

假设我有一个这样定义的模板类

我可以隐式或显式实例化它：

通过显式实例化，即使我以后不使用它，我的程序也应该包含一个实例（假设编译器优化没有省略它）。

我的问题是，以下语句是否会导致类的实例化？

给定以下代码

https://wandbox.org/permlink/j24Pe9qOXV0oHc​​A8

当我尝试编译它时，我收到错误消息，说我不允许在 main 中修改 lambda 中的 const 值。这意味着模板都在类中被实例化，这会导致硬错误，因为错误在 lambda 的主体中。

对此有何规定？为什么重载解析会尝试实例化一个永远不会被调用的模板？永远不应该在这里调用 const ，那么为什么要尝试完全实例化它呢？

然而奇怪的是，当我更改要返回的定义decltype(auto)并添加代码以执行与尾随返回类型建议的相同的事情时，我没有看到错误。表明模板没有被完全实例化？

我猜编译器在使用传递的函数至少实例化签名之前不知道要调用哪个函数。但这并不能解释为什么 decltype(auto) 版本有效......

给定以下代码：

我想实例化和 的不同foo组合X，Y如.ifmain

然而，这可能会变得非常丑陋（长）。给定所需组合的列表，是否有可能使用 C++14（例如通过使用预处理器）生成此代码？

考虑这段代码：

假设sizeof操作符是唯一需要实例化的地方A<double>。编译的程序是否可能不包含A<double>（例如A<double>::~A()）的相关代码？