D 是否有可能避免对独立功能进行重复的常规检查？

我喜欢独立函数，因为我可以调用点积，比如

v1.dot（v2）

或

dot（v1，v2）

，但它们需要更多的编写工作

比如说

浮点数（Vec）（在Vec v1中，在Vec v2中）
if（isVector！（Vec）&&&…）{
....
}

我也有很多不同的功能，只在特定的维度上工作，检查都是重复的

如果我能写些长一点的东西就好了

模板（Vec）
if（isVector！Vec&&…）{
//这里的功能
浮点数（在Vec v1中，在Vec v2中）{..}
浮动长度（在向量v1中，在向量v2中）{..}
浮动长度平方（在向量v1中，在向量v2中）{..}
}

---

我想调用它们，就像每个函数都有自己的模板一样，比如

dot（v1，v2）

。像这样的事情是可能的还是我应该坚持使用方法？

我不太确定我是否能满足你的要求。是否将某个对象作为方法/成员函数取决于您，实际上与函数是否模板化没有多大关系。如果一个函数需要采用特定的类型，那么不管它是自由函数还是成员函数，都可以声明它采用该类型。如果一个函数应该使用多种类型，那么它需要被模板化，在这种情况下，如果其中一个参数总是被认为是一个特定类型，那么它可以是该类型的成员函数，但是，否则，它必须是一个自由函数才能是泛型的

当您有一个模板类型，并且您想要编写一个只接受该类型的自由函数时，会出现问题。您必须对自由函数进行模板化，并测试它所提供的类型是否是该类型的实例化，因此模板约束开始变得更加丑陋和复杂，而成员函数可能是干净的。而不是像

模板向量（T）
如果（…）
{
...
浮点数（向量v1，向量v2）{…}
...
}

你最终得到的是

浮动点（V）（V v1，V v2） 如果（isInstanceOf！（向量，V）） {...} 这是可行的，但它添加了不必要的样板文件，其中唯一的好处是能够执行

dot（v1，v2）

而不是

v1.dot（v2）

。我认为绝大多数的D程序员会认为这是丑陋和不必要的，而且他们通常会想做

v1.dot（v2）

。UFCS的使用使得几乎所有代码都是

a.foo（b）

，而不管

foo

是自由函数还是成员函数。你是我听说的第一个尝试让一切

foo（a，b）

而不是

a.foo（b）

，而且它在一般情况下不起作用，因为许多函数都是成员函数，不能作为自由函数调用，然而，所有函数都可以像调用成员函数一样调用——这就是为什么泛型代码应该倾向于使用UFC。它只是使代码能够处理更多类型，并允许类型提供自由函数作为成员函数的专门化

但是，如果出于任何原因，您有模板化的函数，这些函数通常是您需要（或真正想要）成为自由函数的成员函数，并且您希望减少冗余的模板约束，那么方法就是创建您自己的特性。e、 g

模板myCond（T）
{
枚举myCond=conditionabout1&&conditionabout2&&conditionabout3；
}

这样，您的函数宿主就不必重复其约束的这一部分。e、 g

浮动点（V）（V v1，V v2） if（myCond！V&&dotSpecificCondAboutTV） {...} 浮子长度平方（V）（V v1，V v2） if（myCond！V&&lengthSquaredSpecificCondAboutV） {...} 但是，试图将一组函数组合到一个模板中，以便它们可以共享一个约束实际上只有在它们是成员函数时才能起作用。如果你有

模板向量（V）
如果（…）
{
浮点数（vv1，vv2）{…}
浮点长度平方（vv1，vv2）{…}
}

然后，无论函数在何处使用，都必须使用模板名称，这样就失去了IFTI（隐式函数模板实例化），这就是为什么不必显式实例化模板化函数及其使用的类型。所以，与其得到类似的东西

auto result=dot（v1，v2）；

或

auto result=v1.dot（v2）；

你最终会得到这样的结果

auto result=Vec！向量（v1，v2）；

对于非模板类型或

auto result=Vec！（向量！浮点）（v1，v2）；

对于模板类型

---

最终，你真的需要让这些函数成为成员函数，或者让它们都单独列出，并带有它们自己的模板约束-但是不管怎样，声明你自己的特性来测试普通的东西会减少模板约束的长度，使它们更容易理解和维护。

只粘贴整个

isVector怎么样！Vec&…

零件是否在其自己的模板中？然后，对于每个自由函数，您只需要一个

if

条件。谢谢，我仍然决定使用独立函数，因为数学库执行

点（v1.unit，v2.unit）

或

长度（v1-v2）

似乎更好，即使它添加了一点样板。但这可能只是一种偏好。